Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]

TechWorld with Nana・2 minutes read

Kubernetes is an open-source container orchestration framework that solves problems of high availability, scalability, and disaster recovery for applications with numerous containers. Key components like pods and services are crucial for managing applications, communication, and data storage efficiently in Kubernetes clusters.

Insights

The course offers a blend of theoretical explanations and practical demos for learning Kubernetes, covering basic concepts, architecture, and Minikube installation for local clusters.
Kubernetes YAML configuration files are crucial for creating and configuring components, with hands-on deployment of applications in a Kubernetes cluster.
Stateful sets in Kubernetes manage data persistence for stateful applications like databases, ensuring data consistency and synchronization among pods.
Worker nodes and master nodes play distinct roles in the Kubernetes architecture, with worker nodes running application pods and master nodes managing the cluster state and worker nodes.
Helm simplifies Kubernetes application management through release management, with Helm 3 eliminating the Tiller component for enhanced security and efficiency.

Get key ideas from YouTube videos. It’s free

Recent questions

What is Kubernetes?
Kubernetes is an open-source container orchestration framework developed by Google for managing applications made up of containers in various environments.

Related videos

Summary

00:00

"Kubernetes Course: Theoretical & Practical Learning"

The course is a mix of animated theoretical explanations and hands-on demos for practical learning.
The first part introduces basic Kubernetes concepts, architecture, and main components.
Installation of Minikube for a local Kubernetes cluster is covered, along with creating, debugging, and deleting pods using kubectl.
Explanation of Kubernetes YAML configuration files for creating and configuring components.
Deployment of a simple application in a Kubernetes cluster for hands-on experience.
Advanced topics in the second part include organizing components using namespaces, making apps available externally with Ingress, and using Helm as a package manager.
Detailed exploration of persisting data with volumes, deploying stateful applications with stateful sets, and different Kubernetes service types.
Kubernetes is an open-source container orchestration framework developed by Google for managing applications made up of containers in various environments.
Kubernetes solves problems of high availability, scalability, and disaster recovery for applications with numerous containers.
Key Kubernetes components include pods, services, Ingress, ConfigMap, Secrets, and Volumes for managing applications, communication, configuration, and data storage.

19:08

Database Replication with Stateful Sets in Kubernetes

Replicating a database using a deployment is not feasible due to the database's state being its data, requiring shared data storage for clones or replicas to access the same data.
Stateful sets, a Kubernetes component, manage which pods write to or read from shared data storage, ensuring data consistency for stateful applications like databases such as MySQL, MongoDB, or Elasticsearch.
Stateful sets replicate and scale pods like deployments but focus on synchronizing database reads and writes to prevent inconsistencies.
Deploying database applications with stateful sets in a Kubernetes cluster can be challenging compared to deployments, leading to a common practice of hosting databases externally and using deployments for stateless applications within the cluster.
Having two replicas each of application and database pods load balanced enhances setup robustness, ensuring accessibility even if one node fails until replicas are recreated to avoid downtime.
Core Kubernetes components include pods, services for communication, Ingress for routing traffic, config maps and secrets for external configuration, volumes for data persistence, and pod blueprints with replicating mechanisms like deployments and stateful sets.
Kubernetes architecture involves master and worker nodes, with worker nodes running application pods and containers managed by processes like container runtime, kubelet for scheduling, and kube proxy for intelligent forwarding.
Worker nodes require container runtime and kubelet services, while master nodes manage the cluster state and worker nodes through processes like API server for requests, scheduler for pod scheduling, controller manager for state changes detection, and etcd for cluster state storage.
Adding more master or worker nodes to a Kubernetes cluster enhances its power and resources, allowing for scalability as application complexity and resource demands increase.
Minikube is a one-node Kubernetes cluster running on a virtual box on a local machine for testing Kubernetes components, while kubectl is a command-line tool for interacting with the cluster, communicating with the API server to configure and create components.

38:08

"Cube CTL: Essential Tool for Kubernetes Clusters"

Cube CTL submits commands to the API server to create or delete components on the minicube node.
Minicube setup involves executing commands to create pods, services, etc., through Cube CTL.
Cube CTL is not limited to minicube clusters; it can interact with any type of Kubernetes cluster setup.
Installation of minicube and Cube CTL is essential for practical usage.
Minicube requires a virtualization tool like VirtualBox or Hyperkit for operation.
Installation guides for minicube and Cube CTL are available for various operating systems.
Minicube comes with Cube CTL as a dependency, simplifying the installation process.
Cube CTL commands can be used to check the status of the cluster, nodes, and services.
Creation of Kubernetes components like deployments is done using Cube CTL commands.
Editing deployment configurations can be done to update settings like image versions, automatically managing pods and replica sets.

57:17

Managing Kubernetes Components with Configuration Files

Configuration files gather information about components, their names, images, and options for execution using `kubectl apply` command.
`kubectl apply` command with `-f` option executes configuration files in YAML format, like `nginx deployment`.
Configuration files specify details like creating a deployment, number of replicas, and pod specifications.
`kubectl apply` creates or updates components like deployments, detecting existing ones for updates.
Kubernetes self-healing feature compares desired and actual states, updating configurations accordingly.
Configuration files in YAML format have metadata, specifications, and automatically generated status parts.
Kubernetes uses labels and selectors to connect components like deployments and pods.
Services and pods require port configurations for accessibility and communication.
`kubectl describe` command provides troubleshooting information about components like pods and containers.
`kubectl apply` and `kubectl delete` commands manage components using configuration files, enabling creation and deletion.

01:18:04

Configuring MongoDB Deployment in Kubernetes Cluster

The browser sends a request to an external service of Express, which forwards it to the Express pod.
The Pod connects to the internal service of MongoDB, which is the database URL, and then forwards the request to the MongoDB pod.
Authentication of the request occurs at the MongoDB pod using credentials.
Setting up the entire configuration using Kubernetes configuration files is the next step.
A MiniKube cluster is running, with only a default Kubernetes service present.
The first task is creating a MongoDB deployment using a prepared deployment file in Visual Studio Code.
The deployment file includes metadata, labels, selectors, and a blueprint for parts with one replica.
The MongoDB container's image is specified, along with the port to expose and environmental variables for the root username and password.
A secret is created to store the root username and password securely, with values base64 encoded.
The secret is referenced in the deployment configuration file to ensure secure credential handling.

01:37:49

Configuring MongoDB and Express in Kubernetes

The database server URL is derived from the MongoDB service name, which is then saved as a config map for consistency.
The order of creating the config map and deployment matters, with the config map needing to exist before referencing it in the deployment.
Referencing the config map in the deployment is similar to referencing a secret, with the key-value pair being crucial.
The Express deployment includes standard configurations like exposed Port 8081, image with the latest tag, and essential environmental variables for connecting with MongoDB.
After creating the config map, the Express deployment is applied using 'CTL apply' commands.
Creating an external service for Express involves configuring it similarly to the MongoDB service, with specific ports and a type of load balancer for external access.
The load balancer type assigns an external IP address for accepting external requests, distinct from the internal IP address provided by the cluster IP type.
In MiniKube, obtaining the external IP address for the service is done using the 'minikube service' command.
The usage of namespaces in Kubernetes allows for organizing resources into virtual clusters within a cluster, aiding in resource management and access control.
Namespace creation, resource grouping, and access restrictions within namespaces are essential considerations for effective resource management and isolation in Kubernetes clusters.

01:57:09

Managing Kubernetes Namespace and Ingress Controllers

To list components not bound to a namespace, use the command `cubectl API resources --namespaced false`.
To list resources bound to a namespace, use `namespace true`.
Components without a specified namespace default to the default namespace.
Applying a config map without specifying a namespace creates it in the default namespace.
Using `cubectl apply -f config map` with the namespace flag creates the config map in a specific namespace.
Adjusting the configuration file to include the namespace attribute creates components in a specific namespace.
Changing the default namespace to a chosen namespace can be done using the tool Cube NS.
Installing Cube NS on Mac is done with `Brew install X`.
Ingress is crucial for external access to applications in a Kubernetes cluster.
Ingress controllers evaluate and manage Ingress rules for routing external requests.

02:15:30

Configuring Ingress for Kubernetes Dashboard Access

Internal Kubernetes dashboard service is directed to dashboard.com, identified as internal due to its cluster IP type, lacking an external IP address.
Ingress rule creation is initiated by applying multiple dashboard Ingress yaml files using Cube CTL.
Ingress creation is confirmed by checking for the Ingress in the namespace, with the address initially empty until assigned.
The assigned IP address is then mapped to dashboard.com in the hosts file to enable access locally.
Requests to dashboard.com are routed through the mini Cube cluster to the Ingress controller, which evaluates defined rules and forwards requests to services.
Ingress includes a default backend to handle requests not mapped to any service, preventing default error responses.
Custom error messages can be defined by creating an internal service with the default backend name and port, along with an application for custom error responses.
Ingress configuration allows for more advanced routing beyond basic forwarding, such as defining multiple paths for the same host.
Subdomains can be utilized in Ingress configuration by defining multiple hosts, each representing a subdomain, with one path redirecting requests.
HTTPS forwarding can be configured in Ingress by defining a TLS attribute with the host and referencing a TLS secret containing the certificate and key.

02:35:37

"Managing Kubernetes Applications with Helm"

Helm is a tool that aids in managing Kubernetes applications, with a key feature being release management.
Helm versions 2 and 3 differ significantly, with version 2 having a client-server setup involving Helm client and Tiller server.
Tiller, in Helm version 2, executes requests and creates components in a Kubernetes cluster based on YAML files sent by the Helm client.
Release management in Helm allows for upgrades to existing deployments without recreating them, with the ability to rollback upgrades if needed.
Helm 3 removed the Tiller component due to security concerns, simplifying the tool to just a Helm binary.
Kubernetes data persistence involves using volumes to store data across Pod restarts, crucial for applications like databases.
Persistent volumes in Kubernetes are abstract components that need to be tied to actual physical storage, like local drives or cloud storage.
Kubernetes administrators configure and manage the actual storage, creating persistent volumes for developers to claim for their applications.
Persistent volume claims (PVCs) are used by developers to request storage for their applications, which are then mounted into Pods for data persistence.
Config maps and secrets in Kubernetes are local volume types managed by Kubernetes itself, used for storing configuration files and sensitive data.

02:55:27

Efficient Storage Provisioning in Kubernetes Applications

Admins manually request storage from cloud or storage provider for applications before deployment, creating numerous persistent volumes, which can be time-consuming and messy.
Kubernetes offers a more efficient process through a third component called storage class, dynamically provisioning persistent volumes when needed.
Storage class is configured using a YAML file, defining the provisioner attribute to specify the storage platform or cloud provider for creating persistent volumes.
Each storage backend has its provisioner, either internal (prefixed with kubernetes.io) or external, requiring explicit configuration in the storage class.
Parameters for the storage, like disk type, are configured in the storage class, abstracting the underlying storage provider and its characteristics.
In Pod configuration, storage class is referenced through the storage class name attribute in the PVC configuration to create a persistent volume that fulfills the PVC claims.
Stateful applications, like databases, track state by storing data, unlike stateless applications that handle each request independently without storing previous interactions.
Stateful applications in Kubernetes are deployed using stateful set components, allowing replication of stateful app parts and managing data persistence.
Stateful set maintains a sticky identity for each part, ensuring each part has a persistent identifier and its own storage for data synchronization.
Kubernetes services, like cluster IP, headless, node port, and load balancer services, provide different networking capabilities for applications, each serving specific use cases.

03:14:22

"Kubernetes Services: Stable IP, Load Balancing"

Each pod in Kubernetes has its own internal IP address, but these IPs are ephemeral and change frequently.
Using pod IP addresses directly is not practical due to their changing nature.
Services in Kubernetes provide a stable, persistent IP address in front of each pod.
Services also offer load balancing, directing requests to multiple pod replicas of an application.
Services aid in loose coupling for communication within the cluster and with external services.
The most common service type in Kubernetes is the Cluster IP, which is the default type.
Cluster IP services route requests from Ingress to specific pods based on selectors and target ports.
Kubernetes assigns IP addresses to pods from specific ranges on worker nodes.
Services can handle multiple endpoint requests, such as for databases and monitoring applications.
Headless services in Kubernetes allow direct communication with individual pods, crucial for stateful applications like databases.

03:33:10

Secure External Access with LoadBalancer Service

Service exposure in Kubernetes can be done through different types, such as NodePort, which allows external clients to access worker nodes directly, posing security risks. A more efficient and secure alternative is the LoadBalancer service type, which utilizes the cloud provider's native load balancer to route traffic to the appropriate node port and cluster IP services.
LoadBalancer service type in Kubernetes extends from NodePort and ClusterIP types, providing a more secure and efficient way for external access. By using the cloud provider's load balancer, traffic is directed to the node port on the worker node through the load balancer entry point, ensuring better control and security in service accessibility.

Try it yourself — It’s free.