DevOps & Cloud (AWS, AZURE, GCP) Tech Free Learning

🐳 𝗗𝗼𝗰𝗸𝗲𝗿 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀! 🐳 Docker has revolutionized the world of containerization, enabling scalable and efficient application deployment. To make the most of this powerful tool, here are 10 essential Docker best practices: ✔️ 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮 𝗟𝗶𝗴𝗵𝘁𝘄𝗲𝗶𝗴𝗵𝘁 𝗕𝗮𝘀𝗲 𝗜𝗺𝗮𝗴𝗲: Use minimalist base images to reduce container size and vulnerabilities. ✔️ 𝗦𝗶𝗻𝗴𝗹𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗽𝗲𝗿 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿: Keep it simple - one process per container for better isolation and maintainability. ✔️ 𝗨𝘀𝗲 𝗗𝗼𝗰𝗸𝗲𝗿 𝗖𝗼𝗺𝗽𝗼𝘀𝗲: Define multi-container applications in a YAML file for easy management. ✔️ 𝗩𝗼𝗹𝘂𝗺𝗲 𝗠𝗼𝘂𝗻𝘁𝗶𝗻𝗴: Store data outside the container to preserve it, even if the container is removed. ✔️ 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻: Consider Kubernetes or Docker Swarm for managing containers at scale. ✔️ 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝗶𝗻𝗴 𝗮𝗻𝗱 𝗧𝗮𝗴𝗴𝗶𝗻𝗴: Always tag images with version numbers to ensure reproducibility. ✔️ 𝗛𝗲𝗮𝗹𝘁𝗵 𝗖𝗵𝗲𝗰𝗸𝘀: Implement health checks to monitor container status and reliability. ✔️ 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗟𝗶𝗺𝗶𝘁𝘀: Set resource constraints to prevent one container from hogging resources. ✔️ 𝗗𝗼𝗰𝗸𝗲𝗿𝗳𝗶𝗹𝗲 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀: Optimize Dockerfiles by minimizing layers and using caching effectively. ✔️ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Regularly update images, scan for vulnerabilities, and follow security best practices. 🌐𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🐳 𝗗𝗼𝗰𝗸𝗲𝗿 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀! 🐳 Docker has revolutionized the world of containerization, enabling scalable and efficient application deployment. To make the most of this powerful tool, here are 10 essential Docker best practices: ✔️ 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝗮 𝗟𝗶𝗴𝗵𝘁𝘄𝗲𝗶𝗴𝗵𝘁 𝗕𝗮𝘀𝗲 𝗜𝗺𝗮𝗴𝗲: Use minimalist base images to reduce container size and vulnerabilities. ✔️ 𝗦𝗶𝗻𝗴𝗹𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗽𝗲𝗿 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿: Keep it simple - one process per container for better isolation and maintainability. ✔️ 𝗨𝘀𝗲 𝗗𝗼𝗰𝗸𝗲𝗿 𝗖𝗼𝗺𝗽𝗼𝘀𝗲: Define multi-container applications in a YAML file for easy management. ✔️ 𝗩𝗼𝗹𝘂𝗺𝗲 𝗠𝗼𝘂𝗻𝘁𝗶𝗻𝗴: Store data outside the container to preserve it, even if the container is removed. ✔️ 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻: Consider Kubernetes or Docker Swarm for managing containers at scale. ✔️ 𝗩𝗲𝗿𝘀𝗶𝗼𝗻𝗶𝗻𝗴 𝗮𝗻𝗱 𝗧𝗮𝗴𝗴𝗶𝗻𝗴: Always tag images with version numbers to ensure reproducibility. ✔️ 𝗛𝗲𝗮𝗹𝘁𝗵 𝗖𝗵𝗲𝗰𝗸𝘀: Implement health checks to monitor container status and reliability. ✔️ 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝗟𝗶𝗺𝗶𝘁𝘀: Set resource constraints to prevent one container from hogging resources. ✔️ 𝗗𝗼𝗰𝗸𝗲𝗿𝗳𝗶𝗹𝗲 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀: Optimize Dockerfiles by minimizing layers and using caching effectively. ✔️ 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: Regularly update images, scan for vulnerabilities, and follow security best practices. ❤️ Follow for more: @prodevopsguy

🔥 Basic Kubectl commands which are essential for a DevOps engineer to manage within a Kubernetes cluster. 💠 Pods: ⏩ Create a Pod: kubectl create -f pod.yaml ⏩ Get Pods: kubectl get pods ⏩ Describe Pod: kubectl describe pod <pod_name> ⏩ Logs: kubectl logs <pod_name> ⏩ Exec into Pod: kubectl exec -it <pod_name> -- <command> ⏩ Delete Pod: kubectl delete pod <pod_name> 💠 Deployments: ⏩ Create a Deployment: kubectl create -f deployment.yaml ⏩ Get Deployments: kubectl get deployments ⏩ Describe Deployment: kubectl describe deployment <deployment_name> ⏩ Scale Deployment: kubectl scale --replicas=3 deployment/<deployment_name> ⏩ Rollout Status: kubectl rollout status deployment/<deployment_name> ⏩ Rollout History: kubectl rollout history deployment/<deployment_name> 💠 Services: ⏩ Create a Service: kubectl create -f service.yaml ⏩ Get Services: kubectl get services ⏩ Describe Service: kubectl describe service <service_name> ⏩ Delete Service: kubectl delete service <service_name> 💠 ConfigMaps: ⏩ Create a ConfigMap: kubectl create configmap <configmap_name> --from-file=<file_path> ⏩ Get ConfigMaps: kubectl get configmaps ⏩ Describe ConfigMap: kubectl describe configmap <configmap_name> ⏩ Delete ConfigMap: kubectl delete configmap <configmap_name> 💠 Secrets: ⏩ Create a Secret: kubectl create secret generic <secret_name> --from-literal=<key>=<value> ⏩ Get Secrets: kubectl get secrets ⏩ Describe Secret: kubectl describe secret <secret_name> ⏩ Delete Secret: kubectl delete secret <secret_name> 💠 Nodes: ⏩ Get Nodes: kubectl get nodes ⏩ Describe Node: kubectl describe node <node_name> 💠 Namespaces: ⏩ Get Namespaces: kubectl get namespaces ⏩ Describe Namespace: kubectl describe namespace <namespace_name> 💠 PersistentVolumes (PV) and PersistentVolumeClaims (PVC): ⏩ Get PVs/PVCs: kubectl get pv / kubectl get pvc ⏩ Describe PV/PVC: kubectl describe pv <pv_name> / kubectl describe pvc <pvc_name> ⏩ Delete PV/PVC: kubectl delete pv <pv_name> / kubectl delete pvc <pvc_name> 😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🆘 Here is a list of some 𝗥𝗲𝘀𝘂𝗺𝗲-𝗥𝗲𝗮𝗱𝘆 DevOps projects. ➡️ 𝗗𝗲𝘃𝗦𝗲𝗰𝗢𝗽𝘀 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗣𝗿𝗼𝗷𝗲𝗰𝘁: 𝗗𝗲𝗽𝗹𝗼𝘆 𝗡𝗲𝘁𝗳𝗹𝗶𝘅 𝗖𝗹𝗼𝗻𝗲 𝗼𝗻 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 🔗 https://lnkd.in/gUpEqDuG ➡️ 𝗗𝗲𝗽𝗹𝗼𝘆𝗶𝗻𝗴 𝗮 𝗬𝗼𝘂𝗧𝘂𝗯𝗲 𝗖𝗹𝗼𝗻𝗲 𝗔𝗽𝗽 𝘄𝗶𝘁𝗵 𝗗𝗲𝘃𝗦𝗲𝗰𝗢𝗽𝘀 🔗 https://lnkd.in/gvvzwW2A ➡️ 𝗚𝗶𝘁𝗟𝗮𝗯 𝗖𝗜/𝗖𝗗 𝘂𝘀𝗶𝗻𝗴 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 - 𝗠𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 🔗 https://lnkd.in/gJUfnjHx ➡️ 𝗧𝗛𝗘 𝗨𝗟𝗧𝗜𝗠𝗔𝗧𝗘 𝗖𝗜/𝗖𝗗 𝗣𝗜𝗣𝗘𝗟𝗜𝗡𝗘 🔗 https://lnkd.in/gVUDtZBF ➡️ 𝗖𝗼𝗺𝗽𝗹𝗲𝘁𝗲 𝗥𝗲𝗮𝗹-𝘁𝗶𝗺𝗲 𝗗𝗲𝘃𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗 𝗣𝗿𝗼𝗷𝗲𝗰𝘁 🔗 https://lnkd.in/gn_tMBfi ➡️ 𝗝𝗲𝗻𝗸𝗶𝗻𝘀 𝗖𝗜/𝗖𝗗 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 - 𝗦𝗼𝗻𝗮𝗿𝗤𝘂𝗯𝗲, 𝗗𝗼𝗰𝗸𝗲𝗿, 𝗚𝗶𝘁𝗵𝘂𝗯 𝗪𝗲𝗯𝗵𝗼𝗼𝗸𝘀 𝗼𝗻 𝗔𝗪𝗦 🔗 https://lnkd.in/gzwdXM3y ➡️ 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗖𝗜/𝗖𝗗 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗨𝘀𝗶𝗻𝗴 𝗝𝗲𝗻𝗸𝗶𝗻𝘀 🔗 https://lnkd.in/gC4Zs_H9 ➡️ 𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗗𝗲𝘃𝗦𝗲𝗰𝗢𝗽𝘀 𝗖𝗜/𝗖𝗗: 𝟯-𝗧𝗶𝗲𝗿 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 🔗 https://lnkd.in/grVg76Dw 🔵 Follow for more: @prodevopsguy

➡️ Prometheus Architecture Explained ~ 🔬 Prometheus is an open-source monitoring and alerting toolkit designed for reliability and scalability. Below is a an overview of the Prometheus architecture: 🏮 Components: 📚 Prometheus Server: - Core for collecting, storing, and querying time-series data. - It’s pull-based and scrapes metrics from targets at regular intervals. - Stores data in a local time-series database. 📚 Metrics (Targets/Exporters): - Apps or services expose metrics. - Prometheus scrapes metrics from these targets. 📚 Data Model: - Time-series data with metric names and labels. - Example: `http_requests_total{method="GET", status="200"}`. 📚 PromQL: - Query language for time-series data. - Allows filtering, grouping, and math operations on metrics. 📚 Alertmanager: - Handles alerts from Prometheus. - Manages notifications and integrates with third-party channels. 📚 Storage: - Uses local on-disk storage. - Data retention policies. - Data is organized in blocks and compacted over time. 🏮 Workflow: 📚 Configuration: - Targets and scrape intervals defined in Prometheus config files. - Relabeling allows modifying or filtering metrics before storage. 📚 Scraping: - Prometheus Server scrapes metrics from configured targets. - Targets expose metrics typically at /metrics endpoint. 📚 Storage: - Scraped metrics stored in the local time-series database. - Data organized by metric name and labels. 📚 Querying: - Users utilize PromQL to query and analyze stored metrics. - Grafana or Prometheus's UI visualizes query results. 📚 Alerting: - Prometheus evaluates alerting rules based on queries. - Alerts sent to Alertmanager if conditions are met. 📚 Alertmanager Handling: - Alertmanager receives alerts and manages their lifecycle. - Handles deduplication, grouping, and sends notifications to configured channels. 🏮 Advantages: - Simple configuration for monitoring targets. - Powerful query language (PromQL). - Effective alerting and notification handling. - Seamless integration with visualization tools. ✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

⚙️ Most Common Kubernetes Basic Errors ⚙️

1️⃣. ImageBackPullOff We face this issue when the image is not present in registry or the given image tag is wrong. Make sure you provide correct registry url, image name and image tag. We might face authentication failures, when image is being stored in a private registry, make sure to create secret with private registry credentials and add created secret in Kubernetes Deployment File to pull docker image.

2️⃣. CrashLoopBackOff We face this issue when the process deployed inside container not running then the POD will be moved to CrashLoopBackOff. POD might be running out of CPU or memory, POD should get enough resources allocated that’s cpu and memory for an application to be up and running, to fix that check in Resources Requests and Resources Limits.

3️⃣. OOM Killed - Out Of Memory We face this issue when PODs tries to utilise more memory than the limits we have set. We can resolve it by setting appropriate resource request and resource limit.

4️⃣. POD Status - Pending When nodes might not be ready and required resources like CPU and Memory may not be available in nodes for the PODs to be up and running.

5️⃣. POD Status - Waiting POD will be scheduled to a node but POD won’t be running in scheduled node. We can fix this by providing correct image name, image tag and authentication to registry.

6️⃣. POD will be up and running and application is not accessible. We can fix this by creating appropriate service. If service is already created and application is still not accessible, make sure application and service are deployed in same namespace.

7️⃣. POD Status - Evicted We can resolve this by setting appropriate resource requests and resource limits for the PODs and having enough resources in worker nodes.

✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🔥When becoming a DevOps Engineer, prioritize learning fundamental concepts before technologies. ❌ Just learning technologies and adding them to your resume won't cut it. ✔️ You need to understand the basic concepts. ➡️ For example, before learning docker, learn about Linux Kernel cgroups and namespaces. ✔️ Learn the basics, then learn the technology. ❤️ Follow for more: @prodevopsguy

https://prodevopsguy.github.io/2024/Ultimate-DevOps-Bootcamp-2024-Pack/ ⚠️ Note: Anyone Interested, can open the Blog 🌐, share it to your friends and colleagues. 🔵 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

https://harshhaa.hashnode.dev/deployment-of-super-mario-on-kubernetes-using-terraform Follow 🍩 Like 👍 Share 👍 Comment Your thoughts 💬 🌟 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

😀😀 10 DevOps Real time Scenarios. 😀😀 🚀 Issues as well as their resolutions: 🚀 🔢. Continuous Integration Pipeline Failure and its Resolution. 🔗 https://lnkd.in/g9nBb79u 🔢. Application experiences performance degradation and becomes slow during high-traffic periods and its resolution. 🔗 https://lnkd.in/g9nBb79u 🔢. Deployments are error-prone and inconsistent across different environments and its resolution. 🔗 https://lnkd.in/gE6FYcBz 🔢. The application goes down in production due to an unforeseen issue and its resolution. 🔗 https://lnkd.in/gE6FYcBz 🔢. A security vulnerability is discovered in a component of the application stack and its resolution. 🔗 https://lnkd.in/gPtZ9_Ge 🔢. Production environments start to deviate from their desired configurations over time and its resolution. 🔗 https://lnkd.in/gPtZ9_Ge 🔢. A critical service experiences an outage, impacting users and business operations and its resolution. 🔗 https://lnkd.in/gvTtGYC7 🔢. Communication breakdowns between development and operations teams lead to misunderstandings and delays and its resolution. 🔗 https://lnkd.in/gvTtGYC7 🔢. A major release causes unexpected issues in the production environment. 🔗 https://lnkd.in/gYbFKPrv 🔢🔢. Cloud resource costs are increasing beyond budgeted limits. 🔗 https://lnkd.in/gYbFKPrv 🎄 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

🔥 I have created this handy diagram that breaks down the key concepts of Kafka in a simple and easy-to-understand way. 🔴 𝗣𝗿𝗼𝗱𝘂𝗰𝗲𝗿:

A Kafka producer is an entity that publishes data to topics within the Kafka cluster. In essence, producers are the sources of data streams, which might originate from various applications, systems, or sensors. They push records into Kafka topics, and each record consists of a key, a value, and a timestamp.

🔴 𝗖𝗼𝗻𝘀𝘂𝗺𝗲𝗿:

A Kafka consumer pulls data from Kafka topics to which it subscribes. Consumers process the data and often are part of a consumer group. In a group, multiple consumers can read from a topic in parallel, with each consumer responsible for reading from certain partitions, ensuring efficient data processing.

🔴 𝗧𝗼𝗽𝗶𝗰:

A topic is a category or feed name to which records are published. Topics in Kafka are multi-subscriber; they can be consumed by multiple consumers and consumer groups. Topics are divided into partitions to allow for data scalability and parallel processing.

🔴 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻:

A topic can be divided into partitions, which are essentially subsets of a topic's data. Each partition is an ordered, immutable sequence of records that is continually appended to. Partitions allow topics to be parallelized by splitting the data across multiple brokers.

🔴 𝗕𝗿𝗼𝗸𝗲𝗿:

A broker is a single Kafka server that forms part of the Kafka cluster. Brokers are responsible for maintaining the published data. Each broker may have zero or more partitions per topic and can handle data for multiple topics.

🔴 𝗖𝗹𝘂𝘀𝘁𝗲𝗿:

A Kafka cluster comprises one or more brokers. The cluster is the physical grouping of one or more brokers that work together to provide scalability, fault tolerance, and load balancing. The Kafka cluster manages the persistence and replication of message data.

🔴 𝗥𝗲𝗽𝗹𝗶𝗰𝗮:

A replica is a copy of a partition. Kafka replicates partitions across multiple brokers to ensure data is not lost if a broker fails. Replicas are classified as either leader replicas or follower replicas.

🔴 𝗟𝗲𝗮𝗱𝗲𝗿 𝗥𝗲𝗽𝗹𝗶𝗰𝗮:

For each partition, one broker is designated as the leader. The leader replica handles all read and write requests for the partition. Other replicas simply copy the data from the leader.

🔴 𝗙𝗼𝗹𝗹𝗼𝘄𝗲𝗿 𝗥𝗲𝗽𝗹𝗶𝗰𝗮:

Follower replicas are copies of the leader replica for a partition. They replicate the leader's log and do not serve client requests. Instead, their purpose is to provide redundancy and to take over as the leader if the current leader fails.

✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

🎙 Kubernetes is an open-source 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻 system for automating software deployment, scaling, and management. ➡️ Features: ✅ Load balancing ✅ Self-healing ✅ High availability / Ensure no downtime / Maintain fault tolerance ✅ Performance enhancement ✅ Auto-scaling Several key components of Kubernetes are important to understand: 𝗣𝗼𝗱 ➡️ Represents one or more containers running in a cluster. 𝗦𝗲𝗿𝘃𝗶𝗰𝗲 ➡️ An abstract way to access pod/application. 𝗡𝗮𝗺𝗲𝘀𝗽𝗮𝗰𝗲 ➡️ Used to remove name collision within a cluster. It supports multiple virtual clusters on the same physical cluster. 𝗡𝗼𝗱𝗲 ➡️ Kubernetes worker machine. 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 ➡️ Consisting of a group of nodes running containerized applications on Kubernetes. 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝗦𝗲𝘁 ➡️ Several replicas of running pods. It helps in achieving high availability and scalability. 𝗟𝗮𝗯𝗲𝗹 ➡️ Giving a name to Kubernetes objects so that they can be identified across the system. 𝗞𝘂𝗯𝗲𝗹𝗲𝘁 ➡️ Agent that runs on each node and checks if the containers are running in the pods. 𝗞𝘂𝗯𝗲𝗰𝘁𝗹 ➡️ Command-line utility to interact with the Kubernetes API server. 𝗞𝘂𝗯𝗲-𝗽𝗿𝗼𝘅𝘆 ➡️ Network proxy which contains all the network rules on each node in the cluster. ✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

📢 Sidecar container in kubernetes: Sidecar container is a design pattern where an additional container is deployed alongside the main container within the same Pod. The sidecar container runs in the same execution environment and shares the same resources (network namespace, IPC namespace, etc.) with the main container. Sidecar containers are often used to extend or enhance the functionality of the main application container without modifying its codebase directly. Here are some common use cases for sidecar containers: 📢 Logging: A sidecar container can be used to collect, format, and forward logs generated by the main application container to a centralized logging system. 📢 Monitoring: Sidecar containers can be used to collect metrics, health checks, or other telemetry data from the main application container and expose it to monitoring systems like Prometheus. 📢 Security: A sidecar container can handle tasks such as managing SSL certificates, providing authentication, or enforcing security policies independently of the main application. 📢 Data Processing: Sidecar containers can be used for tasks like data transformation, caching, or pre-processing data before it's consumed by the main application. ✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🟩 🌐 Git/GitHub Free Videos:- 🟩 🔥 ➡️ https://drive.google.com/drive/folders/1vhSsxz9oAtSh136JVo3gryaDPJAYWteF?usp=sharing ❤️ Follow for more: @prodevopsguy

🟩 Ansible 🆓 Videos 🔴 🔗Link : https://drive.google.com/drive/folders/1p35HHSamOyL1Rta8hK5--4k1mPWYAXaV?usp=sharing ❤️ Follow for more: @prodevopsguy