techiescamp/kubernetes-learning-path

If you are planning to use this repo for reference, please hit the star. Thanks!

The Kubernetes Learning Roadmap is constantly updated with new content, so you can be sure you're getting the latest information.

As part of our commitment to helping the DevOps community save money on Kubernetes Certifications, we continuously update the latest voucher codes from the Linux Foundation

If you want to learn Kubernetes, it is important to start with the basics.

That means brushing up on your IT fundamentals first because Kubernetes builds on those.

Once you have a good grasp of the basics, learning Kubernetes can be fun and easy. So don't skip the fundamentals. Take some time to study them before diving into Kubernetes!

Here are the resources to brush up on the core fundamentals to master Kubernetes.

• Learn Container concepts & Container Management Tool- Docker/Podman^{Free Course}
• Understand Distributed system ^Blog
• Understand Authentication & Authorization ^Blog
• Learn Basics of Key Value Store^Blog
• Learn the basics of REST API^Blog
• Learn YAML^Blog
• Understand Service Discovery ^Blog
• Learn Networking Basics
  • L4 & L7 Layers (OSI Layers)^Blog
  • SSL/TLS^Blog
  • Network Proxy Basics^Blog
  • DNS^Blog
  • IPTables^Video & NFTables^Video
  • Software Defined Networking (SDN)^Blog

Refer to the following documents to learn about every Kubernetes component in detail.

• Kubernetes Architecture Explained^Blog

The following image shows the high-level Kubernetes architecture and how external services connect to the cluster.

Launching large clusters in the cloud can be costly. So utilize the available cloud credits to practice deploying clusters as if you work on a real project. All cloud platforms offer managed Kubernetes services.

• GKE -Google Cloud $300 free credits^{Cloud Platform}
• EKS - AWS $300 free POC credits^{Cloud Platform}
• DO Kubernetes - Digital Ocean – $200 free credits^{Cloud Platform}
• Linode Kubernetes Engine - Linode Cloud – $100 Free credits^{Cloud Platform}
• Vultr Kubernetes Engine - Vultr Cloud - $250 Free Credits^{Cloud Platform}
• AKS - Azure Cloud Hosting - $200 Free Credits^{Cloud Platform}

As DevOps engineers, gaining a thorough understanding of each component and cluster configuration is crucial to work in production environments. Though there are various methods for deploying a Kubernetes cluster, it is advisable to learn how to set up multi-node clusters from scratch. This allows you to gain knowledge on concepts such as High Availability, Scaling, and Networking and simulates a real-world project.

Additionally, mastering the configuration of multi-node clusters can be beneficial for interviews and building confidence in your abilities. The following are recommended ways to establish a Kubernetes cluster.

• Kubernetes the Hard Way^Github
• Kubeadm Cluster Setup^Blog
• Minikube Development Cluster ^Blog
• Kind Development Cluster^{Official Documentation}

Following are some of the important cluster administrative tasks

• Deploy Kubernetes Dashboard^{Official Doc}
• Important Kubernetes Cluster Configurations^Blog
• Kubeadm Cluster Upgrade^Blog
• etcd backup using etcdctl^Blog

As a DevOps engineer, it is important to become familiar with the Kubeconfig file. It is crucial for tasks such as setting up cluster authentication for CI/CD systems, providing cluster access to developers, and more.

A Kubeconfig file is a YAML file that stores information and credentials for connecting to a Kubernetes cluster. It is used by command-line tools such as kubectl and other client libraries to authenticate with the cluster and interact with its resources.

The Kubeconfig file can be used to store information for multiple clusters and users, allowing users to switch between different clusters and contexts easily. It is an important tool for managing access to and interacting with Kubernetes clusters.

Refer to the following document to learn about the Kubeconfig File in detail.

• Kubeconfig File Explained With Practical Examples ^Blog

In Kubernetes, an object is a persisted entity in the cluster that represents a desired state of the system. It is created and managed by the Kubernetes API server and is stored in the etcd key-value store. Examples of Kubernetes objects include pods, services, and deployments.

Here is an example of a Pod Object

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

A resource is a representation of a Kubernetes object that is exposed by the Kubernetes API. It is a way for clients to interact with and manipulate objects in the cluster.

A resource refers to a specific API URL used to access an object. Resources are typically accessed through the Kubernetes API using HTTP verbs such as GET, POST, and DELETE. For instance, the /api/v1/pods resource can be used to retrieve a list of v1 Pod objects. Additionally, an individual v1 Pod object can be obtained from the /api/v1/namespaces/namespace-name/pods/pod-name resource.

Detailed Blog: Kubernetes Objects & Resources Explained

Every object in Kubernetes is represented/created using a YAML file. Kubernetes has many native objects (20+), however, every object YAML follows a hierarchical structure as shown below.

apiVersion: <API version>
kind: <Kind of object>
metadata:
  name:  <Name of the object>
spec:
  <Specification of the object>>

Here is what each section means.

• apiVersion: Specifies the Kubernetes API version used for the object.
• kind: Defines the type of Kubernetes object being created or modified.
• metadata: Contains information about the object.
• spec: Defines the desired state of the object, including its configuration and behavior. Under spec, there could be many subfields depending on the object type.

The structure remains the same for all native Kubernetes objects. While learning about each object, you can check the hierarchy, and you will be able to relate.

All the essential concepts in Kubernetes center around the Pod. Understanding Pods in detail, along with their supported features, is crucial for anyone working with Kubernetes because many other objects in Kubernetes are built around them. Below are comprehensive guides that delve into various aspects of the Pod with real-world practical examples.

• Kubernetes Pod Explained ^Blog
• multi-container pods^Blog
• Init Containers Explained ^Blog
• Pod Lifecycle Phases^Blog
• Pod Priority, PriorityClass, and Preemption^Blog
• Pod Quality or Service - QoS^Blog
• Troubleshoot Pod^Blog
• Container Lifecyle Hooks^{Official Doc}
• Pod Disruption Budget^Blog
• Pod Affinity/Anti-Affinity^Blog
• Pod Labels & Selectors^Blog

In the topics above, we've covered all the core concepts of Pods that are used in production-level implementations. You should practice these concepts hands-on. Once you have a solid practical understanding of Pods, you can move on to learning about objects that depend on Pods.

Running applications on a single pod can be a single point of failure. That's why Kubernetes provides various objects that use pods to make applications highly available.

Makes sure a specific number of pod replicas are running at all times. If a pod crashes, the ReplicaSet starts a new one.

Use Case: Good for stateless applications where you need multiple identical pods.

Detailed Blog: Replicaset Guide

Manages ReplicaSets and allows for easy updates and rollbacks. It also scales the number of pod replicas.

Use Case: Useful for stateless applications and when you need to update or rollback easily.

Detailed Blog: Deployment Explained

Like a Deployment, but for stateful applications. It gives each pod a unique identity.

Use Case: Good for databases and other stateful applications.

Detailed Blog: Statefulset Explained

Ensures that each node in the cluster runs a copy of a pod.

Use Case: Useful for node monitoring or logging agents.

Detailed Blog: Daemonset Explained

Creates one or more pods and ensures that a specified number of them are completed successfully.

Use Case: Good for batch processing tasks.

Detailed Blog: Kubernetes Jobs Practical Guide

Like a Job, but runs at specific times or intervals.

Use Case: Useful for scheduled tasks like backups.

Detailed Blog: Kubernetes CronJobs Practical Guide

Applications deployed on Pods using deployments may need to be accessed either internally within the cluster by other services or externally from outside the cluster.

The feature that facilitates this access to Pods is known as Services in Kubernetes.

Services provide a stable IP address and DNS name, enabling seamless communication and load balancing among Pods, regardless of their lifecycle changes. This ensures that the network connectivity to applications remains consistent and reliable.

Detailed Blog: Kubernetes Service Explained Visually

Applications running inside Kubernetes require more than just a single endpoint. For instance, if you are running an e-commerce microservice application, you may need to route incoming requests to multiple backend services based on the request path. This is where the Ingress object comes into play.

Ingress Acts like a "front door" to manage incoming traffic to multiple Kubernetes backend services. It Works at Layer 7 (Application Layer) of the OSI model, meaning it can understand HTTP and HTTPS.

Using an Ingress object you can define a set of rules for how traffic should be routed. For example, you can set up rules to send traffic for "www.example.com/shop" to a "shop" service and "www.example.com/blog" to a "blog" service. The only work of ingress is to maintain the routing rules.

Detailed Blog: Kubernetes Ingress Explained

An Ingress Controller is the part that actually makes the Ingress work. It is software that runs inside your cluster and listens for changes to DNS/routing rules from the Ingress object. The software could be Nginx, HAproxy, evvoy, etc.

Detailed Blog: Ingress Controller Explained With Practical Example

Ingress Controller Comparison Comparison of Kubernetes Ingress controllers

Gateway API is like an upgraded version of the Ingress system. It lets you define how traffic should be handled in a more detailed way. For example, you can specify different kinds of load balancing, or set up more complex routing rules.

Official Documentation: Gateway API Documentation

Kubernetes Network Policy is like a set of rules for how pods can talk to each other.

• Detailed Doc: Kubernetes Network Policy
• Useful Tool: Network Policy Editor
• Examples: Network Policy Recipes

Logging is an important aspect of Kubernetes.

Detailed Logging Guide: Kubernetes Logging

Securing a Kubernetes cluster is not just a good practice; it's a necessity.

• The first reason is data protection. You store a lot of sensitive information in your cluster, and the last thing you want is unauthorized access to it.

• Second, there's the integrity of your system. If someone gains unauthorized access, they can disrupt your operations, leading to downtime and potentially significant financial loss.

• Compliance is another big factor, especially for businesses in regulated industries like healthcare or finance. You have to meet certain security standards, and a secure cluster is a step in that direction.

• Lastly, there's the cost factor. Dealing with a security breach can be far more expensive than investing in security measures upfront.

• Kubernetes CIS Benchmarking: CIS Benchmarking using Kube-bench^Blog

• Runtime Security Getting Started With Falco^Blog

• Policy Enforcement: Open Policy Agent Guide^Blog

Now that you have a basic understanding and practical knowledge of Kubernetes, you can begin exploring advanced Kubernetes concepts to further increase your knowledge.

Admission Controllers:^{Official Blog} These are plugins that intercept requests to the Kubernetes API server before the persistence of the object, but after the request is authenticated and authorized.

Dynamic Admission Controller:^{Official Doc} These are HTTP callbacks that receive admission requests and let you implement custom admission logic. There are two types of admission webhooks:

• Validating Admission Webhooks: They can be used to perform validations on Kubernetes objects and reject requests that do not meet certain criteria.
• Mutating Admission Webhooks:^Blog They can be used to modify Kubernetes objects before they are stored (for example, to inject sidecar containers into pods).

Custom Resource Definitions (CRDs):^{Official Doc} Extend Kubernetes API to create custom resources.

Custom Resource & Controllers:^{Official Doc} Custom Resources in Kubernetes are like adding your own new types of objects. Just like you have built-in objects like Pods, Deployments, and Services, you can create your own. This is useful when you want to introduce new concepts or configurations that Kubernetes doesn't already know about.

Custom Controllers are like the rules or instructions for what to do with your new custom resources. They watch for any changes to your custom resources and then make things happen in response.

Custom Schedulers:^Blog By default, Kubernetes uses a default scheduler to assign pods to nodes. However, you might have specific scheduling requirements that aren't addressed by the default scheduler. In such cases, you can create a custom scheduler that can coexist with the default scheduler. You can then specify which scheduler to use for each pod. Custom schedulers allow you to implement complex, custom scheduling logic that might be unique to your application's needs.

The Kubernetes Operator pattern is a way to extend the capabilities of a Kubernetes cluster. It allows you to automate tasks that you would usually do manually.

An Operator is basically a set of custom k8s resources and a custom controller. The custom resources define what you want to happen, like the settings or features you want for an application. The custom controller watches these resources and makes sure the actual state matches what you've defined.

For example, let's say you have a database. Normally, you'd have to manually set it up, scale it, and handle backups. With an Operator, you can automate all these tasks. You just tell the Operator what you want by setting some custom resources, and it takes care of the rest.

One real-world example is the Prometheus Operator. If you want to set up Prometheus for monitoring in your cluster, you'd usually have to do a lot of manual work. The Prometheus Operator automates this. You just set your desired settings in a custom resource, and the Operator sets up and manages Prometheus for you.

Kubernetes Operators: Kubernetes Operators Explained With Examples

Operator Framework: Operator Framework

Python Operator Framework Kopf

CRD Framework Kubebuilder

Custom Admission Webhooks Simple Kubernetes Admission Webhook

Helm and Kustomize are both tools that are used to manage Kubernetes manifests. They are similar in many ways but have some key differences.

Helm is a package manager for Kubernetes that allows users to easily install, manage, and upgrade applications on a Kubernetes cluster. It uses a concept called "charts" which are pre-configured sets of Kubernetes resources that can be easily deployed, upgraded, and rolled back.

Kustomize, on the other hand, is a tool that allows users to customize and configure existing Kubernetes manifests. It uses a concept called "patches" which can be applied to existing manifests to customize them for different environments and use cases. Unlike Helm, Kustomize does not include built-in support for versioning and rollback, and does not have a concept of "packages" or "repositories".

• Learn to Create Helm Chart From Scratch^{Hands-On Blog}
• Kuztomize Crash Course^{Free Course}
• Making the most out of Helm templates^Blog

GitOps is a technical practice that uses Git as a single source of truth for declarative infrastructure and application code.

• Guide to GitOps^{Official Doc}

Some popular GitOps-based tools for deploying applications to Kubernetes clusters are:

• Argo CD^{Official Doc}
• Argo Rollouts^{Official Doc}
• FluxCD^{Official Doc}
• JenkinsX^{Official Doc}

• Learn About 12 Factor Apps ^{Official Guide}
• Production Readiness Checklist^Blog
• Recycling Kubernetes Nodes - Yelp^Blog

Capacity planning is a key aspect of Kubernetes implementation. It's essential for cost savings, performance, resource allocation, scalability, and optimization, among other things.

• Kubernetes Node Capacity ^Blog
• Rightsize the requests^Blog
• Kubernetes Instance Calculator^{Tool & Doc}
• Saving Millions of Dollars by Bin-Packing ClickHouse Pods in AWS EKS^Blog

If you do not have real-world Kubernetes experience, it is better to read case studies of other companies using kubernetes.

• List of Kubernetes User Case Studies^{Official Case Studies}
• Scheduling 300,000 Kubernetes Pods in Production Daily ^Video
• How OpenAI Scaled Kubernetes to 7,500 Nodes^Blog
• Testing 500 Pods Per Node^Blog
• Dynamic Kubernetes Cluster Scaling at Airbnb^Blog
• Scaling 100 to 10,000 pods on Amazon EKS^Blog
• Kubernetes Infrastructure At Medium^Blog
• EKS architecture to improve resiliency^Blog
• Scaling Amazon EKS to thousands of nodes^Blog

• Learn From Kubernetes Failure Stories ^{List of Blogs}
• Reddit: The Pi-Day Outage^Blog
• How a Production Outage Was Caused Using Kubernetes Pod Priorities^Blog

• EKS Workshop
• EKS Best Practices
• EKS Hardening
• EKS Helm Charts
• EKS Blueprints