Kubernetes is a vast and complex topic; knowing where to start can be overwhelming. Learning everything about Kubernetes all at once is a large undertaking that requires significant and sometimes overwhelming effort. When learning a new technology such as Kubernetes, it can be easier to identify the fundamental topics, establish a solid foundation, and dive deeper.

In this article, we're doing just that, using the 80/20 rule. Applying the Pareto Principle (the 80/20 rule) to learning a new subject like Kubernetes means focusing on the 20% of concepts and skills that will provide you with 80% of the value or understanding. Instead of trying to master every detail from the start, you concentrate on the core areas—like container orchestration, deploying applications, and basic networking—that will allow you to be productive and effective quickly. Once you’ve grasped these fundamentals, you can gradually explore more advanced topics as needed. This approach helps you learn efficiently, avoid being overwhelmed, and quickly gain practical knowledge.

Here’s how you can do it

1. Identify Key Concepts and Components:

• Focus on 20% of the foundational Kubernetes concepts, giving you a solid understanding of the system. This includes understanding pods, nodes, clusters, namespaces, services, and the Kubernetes control plane. Scroll down to the next section to dive into the 20%.

2. Leverage Top Resources:

• Utilize the most authoritative and comprehensive resources covering essential information. See this list of The Best Kubernetes Books of All Time.

3. Focus on High-Impact Tools and Practices:

• Learn and practice the tools and workflows widely adopted in the Kubernetes ecosystem and contribute to most practical use cases, such as Helm for package management and Prometheus for monitoring. See the paragraphs below for getting started with these tools.

4. Engage with the Community:

• Participate in community events, forums, and meetups where you can interact with experts and peers. Platforms like the Kubernetes Slack channel, CNCF events, or local Kubernetes meetups (like KCD Texas and the Austin Kubernetes meetup) can provide concentrated and valuable insights.

• Watch this video about Kaslin's experience in the Kubernetes community:

Key Concepts and Components

1. Kubernetes Architecture

• Nodes and Clusters: To understand the basic building blocks, one must consider the roles of a control plane node and a worker node. The control plane is a critical component in Kubernetes because it maintains all the parts of the Kubernetes system. You can authenticate to the Kubernetes RESTful API. Often, Kubernetes administrators use a kubeconfig with the kubectl command line to interact with their cluster and perform create, read, update, and delete (CRUD) operations on the API. Worker nodes run workloads running inside of pods. Also, additional components that run both on the control plan and worker node are kube-proxy, the CNI, kubelet, and a container runtime like containerd. The kubelet usually runs as a daemon on the Linux host. It communicates with the Kubernetes API server to receive instructions and report the status of the node and the workloads running on it. The kube-proxy component handles network communication for services, including forwarding traffic to the correct Pods, load balancing, and implementing network policies. The container runtime pulls container images, starts and stops containers, and manages container storage and networking. The Container Networking Interface (CNI) is a plugin in Kubernetes that allows pod-to-pod communication across nodes.

• 

  Control Plane Components: Includes etcd (for cluster state), API Server, Controller Manager, and Scheduler. These all run as pods in the Kubernetes cluster in a namespace named kube-system (Different namespaces can be used to separate environments such as development, staging, and production). The API server is the front end for the Kubernetes control plane. It exposes the Kubernetes API and serves as the hub for communication between other components. The etcd datastore is a consistent and highly available key-value store used as Kubernetes’ backing store for all cluster data. Every state change and configuration in the cluster is stored in etcd. The scheduler assigns workloads (pods) to specific nodes in the cluster based on resource availability, policy constraints, and affinity specifications. The controller manager runs the controllers and regulates the system's state. The controllers include the Node Controller, Replication Controller, and Service Account Controller.

  

2. Pods

• A pod is the smallest deployable unit in Kubernetes and can contain one or more containers. Check out this FREE lab environment, where you can deploy a pod to a Kubernetes cluster (with step-by-step instructions). 😃

3. Services

• The Types of Services in Kubernetes are ClusterIP, NodePort, and LoadBalancer. A primary purpose of Services in Kubernetes is to avoid modifying your existing application to use an unfamiliar service discovery mechanism. You can run code in Pods, whether this is code designed for a cloud-native world or an older app you've containerized. Then, you use a service to make that set of pods available on the network so clients can interact with them.

4. Deployments

• A deployment is a higher-level abstraction that manages a group of identical Pods, ensuring they are running and up-to-date. Deployments provide declarative updates for Pods and ReplicaSets, enabling automated rollout and rollback of applications.

• Check out this FREE guided Kubernetes Lab to try it out for yourself!

5. ConfigMaps and Secrets

• ConfigMaps decouples configuration artifacts from image content to keep containerized applications portable. ConfigMaps allow you to store configuration data as key-value pairs that your application pods can consume.

• Secrets are objects that store and manage sensitive information, such as passwords, OAuth tokens, SSH keys, and other data you want to keep out of plain text in your configuration files. Secrets allow you to securely inject sensitive data into your application pods.

• Create configMaps and use then with pods in this FREE Kubernetes Lab environment!

6. Volumes and Persistent Storage

• In Kubernetes, volumes are used to manage and persist data for containers running in Pods. Unlike ephemeral container storage, which is lost when a container crashes, volumes allow data to be preserved, shared between containers within a Pod, and made persistent across Pod restarts. If you require to store data, you can use different types, such as emptyDir, hostPath, and Persistent Volumes (PVs).

• Persistent Volume Claims (PVCs) request storage resources defined by a Persistent Volume. PVCs provide an abstraction for requesting and using storage without knowing the underlying details. Get hands-on with PVs and PVCs in this FREE Kubernetes lab environment.

9. Ingress

• An Ingress is an API object that manages external access to services within a cluster, typically HTTP and HTTPS. Ingress can provide load balancing, SSL termination, and name-based virtual hosting, making it a powerful way to expose services to external users.

10. RBAC (Role-Based Access Control)

• Role-Based Access Control (RBAC) in Kubernetes regulates access to the Kubernetes API and resources within a cluster. RBAC allows administrators to define roles with specific permissions and then assign those roles to users or groups, ensuring that only authorized individuals can perform certain actions.

• A Role contains a set of permissions (rules) that apply within a specific namespace. It defines what actions can be performed on which resources. A RoleBinding grants the permissions defined in a Role to a user, group, or service account within a specific namespace.

14. Autoscaling

• A Horizontal Pod Autoscaler adjusts the number of Pods in a Deployment, Replica Set, or Stateful Set based on observed CPU utilization, memory usage, or other custom metrics.

• A Cluster Autoscaler scales the cluster size up or down by adding or removing nodes to match the resource requirements of the running Pods.

17. StatefulSets

• A StatefulSet is a controller that manages deploying and scaling a set of Pods and guarantees their ordering and uniqueness. StatefulSets are used for applications that require stable, unique network identifiers, persistent storage, and ordered deployment and scaling, like a database.

• Create and manage a statefulSet in this FREE Kubernetes lab environment!

18. DaemonSets

• a DaemonSet is a type of controller that ensures a copy of a specific Pod runs on each node in a cluster. DaemonSets are particularly useful for deploying system-level or cluster-wide services that need to run on every node, such as log collectors, monitoring agents, and network plugins

19. Jobs and CronJobs

• a Job is a controller that ensures a specified number of Pods successfully terminate. Jobs are used to run tasks that have a clear start and end, such as batch processing, data analysis, or one-time scripts. Once the tasks specified by the Job are completed successfully, the Job itself is considered complete

• a CronJob is a specialized type of Job that runs on a schedule. CronJobs perform tasks regularly, much like the cron utility in Unix-like operating systems. They are suitable for recurring tasks such as backups, report generation, and periodic maintenance.

20. Security

• Pod Security Standards (PSS) in Kubernetes are predefined security policies that outline best practices for running Pods securely. These standards help Pods adhere to specific security guidelines, reducing the risk of vulnerabilities and security breaches. The PSS are typically enforced using Pod Security Admission (PSA), an admission controller that applies these standards at the namespace level. Get hands-on with PSS in this FREE hands-on lab!

• Network Policies in Kubernetes are a way to define rules for controlling the traffic flow between Pods, and between Pods and external endpoints. They allow you to specify how Pods are allowed to communicate with each other and other network endpoints, enhancing security by isolating different parts of your applications and services. Create your first Network Policy in this FREE Kubernetes Lab!

Focusing on these areas will provide a solid foundation in Kubernetes and cover the core aspects you need to understand and effectively use the platform. For deeper learning, you can dive into each of these topics with detailed resources and hands-on practice.

High-Impact Tools and Practices: Helm

Learning and practicing with Helm can significantly enhance your understanding of Kubernetes by simplifying the management and deployment of applications. Helm is a package manager for Kubernetes that helps you define, install, and upgrade complex Kubernetes applications. Here’s a step-by-step guide to learning and practicing with Helm.

To understand the verbiage used in Helm, here are the three Helm Components:

1. Helm Client: The command-line tool used to interact with Helm.

2. Helm Chart: A package that contains all the necessary Kubernetes manifest files to deploy an application.

3. Release: An instance of a Helm chart running in a Kubernetes cluster.

Install Helm on your local machine:

• Helm Installation: Follow the official installation guide for Helm.

• Helm Installation Guide

Example for installing Helm on macOS using Homebrew:

brew install helm

Example for installing Helm on Linux:

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Access a FREE Kubernetes Lab environment on Killercoda.com.

Familiarize yourself with basic Helm commands:

• helm search: Search for Helm charts.

• helm repo add: Add Helm chart repositories.

• helm install: Install a Helm chart.

• helm list: List installed Helm releases.

• helm upgrade: Upgrade an existing Helm release.

• helm uninstall: Uninstall a Helm release.

Example:

# Add the official stable repository
helm repo add stable https://charts.helm.sh/stable

# Update the repository
helm repo update

# Search for a chart
helm search repo stable

# Install a chart
helm install my-release stable/nginx

# List releases
helm list

# Upgrade a release
helm upgrade my-release stable/nginx

# Uninstall a release
helm uninstall my-release

Learn how to create your own Helm charts:

This command creates a directory structure for your chart, including default templates and values:

# create a new chart
helm create mychart

Understanding Chart Structure:

• Chart.yaml: Contains metadata about the chart (name, version, description).

• values.yaml: Default configuration values for the chart.

• templates/: Contains Kubernetes manifest templates.

Customize the Chart:

Modify the values.yaml and templates to suit your application’s needs.

Install the Chart:

helm install my-release ./mychart

Upgrade the Chart:

helm upgrade my-release ./mychart

Uninstall the Chart:

helm upgrade my-release ./mychart

Helm Community and Resources

Engage with the Helm community and utilize available resources:

• Helm Documentation: The official documentation provides comprehensive guides and references.

• Helm GitHub Repository: Explore the source code and contribute.

• Community Forums and Slack: Join discussions and seek help from the community.

High-Impact Tools and Practices: Prometheus

Learning and practicing with Prometheus in the context of Kubernetes is a great way to understand the fundamentals of monitoring and observability in cloud-native environments. Prometheus is widely used for monitoring and alerting in Kubernetes clusters and plays a key role in the Kubernetes ecosystem. Here’s a step-by-step guide to help you learn and practice with Prometheus to understand Kubernetes better.

Key components of Prometheus:

1. Prometheus Server: Responsible for scraping and storing metrics data.

2. Prometheus Query Language (PromQL): A flexible query language for querying metrics data.

3. Alertmanager: Manages alerts generated by Prometheus.

4. Exporters: Applications that expose metrics in a format that Prometheus can scrape (e.g., Node Exporter for hardware metrics).

Access Prometheus using the instructions in this FREE hand-on lab.

Once Prometheus is running, start exploring its features.

Run Basic PromQL Queries, like this one, to get the CPU usage percentage per node:

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)

This is the expected output from the above PromQL query:

Or this one, to monitor memory usage:

sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) by (instance) / sum(node_memory_MemTotal_bytes) by (instance) * 100

This is the expected output from the above PromQL query:

Or this one to count the number of running pods

count(kube_pod_info)

This is the expected output from the above PromQL query:

Engage with the Prometheus Community

• Join the Prometheus Community: participate in discussions, ask questions, and learn from others in the community.

• Contribute to Prometheus: Explore the Prometheus GitHub repository and contribute to the project.

• Explore Prometheus Documentation: The official Prometheus documentation is an excellent resource for in-depth learning.

Summary

Now that you have the 20%, what’s next? Each topic we've touched on has countless avenues to explore further. I recommend joining a learning community where you can connect with others who share your passion for technology. At KubeSkills, we offer a friendly and supportive environment where you can dive deeper and continue your journey. If you found this guide helpful, share it on social media and use it as you see fit. We have more guides like this and more in the KubeSkills community, which you can join for FREE! Thank you for your time and attention if you've read this far.

I look forward to seeing you in the KubeSkills community soon! 😃

-Chad