DAY-37 | KUBERNETES SERVICES DEEP DIVE| LIVE DEMO | LEARN TRAFFIC FLOW USING KUBESHARK | #kubernetes

Name: DAY-37 | KUBERNETES SERVICES DEEP DIVE| LIVE DEMO | LEARN TRAFFIC FLOW USING KUBESHARK | #kubernetes
Uploaded: 2023-03-03T15:31:52.000Z
Duration: 1 h 28 min 17 s

Introduction to Kubernetes Services

In this section, the instructor introduces the topic of Kubernetes services and explains that the class will focus on practical sessions related to load balancing, service discovery, and exposing applications in Kubernetes.

Deep Dive into Kubernetes Services

The session will cover practical aspects of Kubernetes services, including load balancing, service discovery, and exposing applications.

The instructor recommends watching the entire video as it includes a practical demonstration using Cube Shark, a tool for understanding traffic flow within Kubernetes.

Cube Shark helps visualize how components in Kubernetes communicate with each other.

The session will demonstrate various capabilities of services, such as load balancing across multiple pods and pod discovery.

Exposing applications both within the cluster and to the outside world will also be covered.

Setting up the Kubernetes Cluster

This section focuses on setting up a Kubernetes cluster for the demonstration.

Checking MiniKube Status

The instructor already has a MiniKube Kubernetes cluster set up for the demo.

Running minikube status confirms that the cluster is up and running.

Clearing Existing Resources

To start with a clean slate, existing resources in the default namespace are cleared using kubectl delete deploy and kubectl delete svc.

The default service provided by Kubernetes itself is not removed.

Repository for Demo Images

For the demo, the instructor uses images from a repository called "Docker 0 to 0."

Viewers can either use this repository or their own custom images.

The repository contains real-time practical Python and Golang images for front-end and back-end applications.

The GitHub repository link is provided for reference.

Creating a Deployment in Kubernetes

This section covers the process of creating a deployment in Kubernetes.

Accessing the Python Application

The instructor navigates to the "examples" folder and selects the Python application for demonstration.

The Dockerfile and requirements.txt files are present in the repository.

Creating a Deployment

A deployment is created to deploy the selected Python application onto the Kubernetes cluster.

Deployments create replica sets, which in turn create pods.

By default, these pods are only accessible within the Kubernetes cluster.

Understanding Cluster IP Accessibility

This section explains the limitations of accessing pods using cluster IP addresses within a Kubernetes cluster.

Limitations of Cluster IP

Pods created by deployments have a default cluster IP address.

However, this cluster IP is only accessible within the Kubernetes cluster itself.

Deployment on Kubernetes

In this section, the speaker discusses the process of deploying an image onto a Kubernetes cluster. They explain that syntaxes do not need to be memorized and provide guidance on modifying fields in a deployment file.

Creating a Deployment File

The speaker advises going to the Kubernetes deployments page and copying an example deployment.

The copied example is saved as "deployment.yaml" and opened for editing.

Fields such as replicas, name, labels, and selectors are modified according to the requirements.

Labels are important for resource identification and should be added to every resource in Kubernetes.

The container name can be chosen freely, but the image needs to be replaced with the created image.

Port Configuration and Deployment Creation

This section focuses on configuring the port for the application and creating the deployment using kubectl commands.

Configuring Port and Image

The speaker explains that developers or DevOps engineers should know which port their application is running on. This information can be found in the Dockerfile or command line used to run the application.

The container port is updated in the deployment.yaml file with this information.

The image name is also updated with the previously created image.

Creating Deployment

To create the deployment, use kubectl apply -f deployment.yaml.

After successful creation, use kubectl get deploy to verify that the deployment was created along with its associated pods.

Retrieving Information about Deployed Pods

This section covers how to retrieve information about deployed pods using kubectl commands.

Checking Pod Information

Use kubectl get pods command to view all pods associated with a specific deployment.

To obtain IP addresses of these pods, use kubectl get pods -o wide.

Verbose Output and API Server Connection

This section explains how to obtain more detailed information about kubectl commands using verbose output.

Using Verbose Output

By adding the -v flag followed by a verbosity level, such as kubectl get pods -v=7, more detailed information about the command execution is displayed.

The verbose output includes loading the kubeconfig file, connecting to the API server, making API calls, and receiving responses.

The transcript is already in English.

Understanding Kubernetes Deployments and Service Discovery

In this section, the instructor explains the concept of Kubernetes deployments and the need for service discovery in managing dynamic IP addresses.

Kubernetes Deployments

A deployment is a high-level wrapper that rolls out a replica set to ensure that the state of pods matches the deployment.yaml file.

When a pod is deleted, the replica set creates a new pod with the same label.

Dynamic allocation of IP addresses in Kubernetes can lead to traffic loss if IP addresses change when new pods are created.

Service Discovery Mechanism

Kubernetes Services use labels and selectors to identify pods consistently, even if their IP addresses change.

Labels act as stamps or tags for pods, ensuring that each new pod has the same label as its predecessors.

Service discovery mechanisms rely on matching labels and selectors to route traffic correctly.

Accessing Applications in Kubernetes Deployments

This section demonstrates how to access applications running within Kubernetes deployments using curl commands.

Accessing Applications

To access an application within a deployment, use curl followed by the specific IP address and port on which the application is running.

The context root of the application may also need to be specified, such as /demo in this case.

By accessing the application using its IP address and context root, you can observe traffic flow and interact with it.

Summary: Static Application Traffic Flow

The instructor summarizes how traffic flows through a static application running within a Kubernetes deployment.

Traffic Flow

By accessing the static application using its IP address, you can see a message promoting learning DevOps with strong foundational knowledge.

The problem arises when multiple users try to access the same IP address but encounter different pods due to dynamic allocation of IP addresses.

Service discovery mechanisms using labels and selectors help ensure that traffic is correctly routed to the appropriate pods.

The transcript provided does not contain enough information to create additional sections.

Accessing a Kubernetes Cluster Network

In this section, the speaker discusses how to access a Kubernetes cluster network and addresses the challenges of accessing it for both internal and external customers.

Accessing the Cluster Network

By default, a pod in Kubernetes only has the cluster network attached to it.

To access the cluster network, one needs to log into the cluster and access it.

However, this is not ideal for customers who are outside the organization.

Internal Customers

For internal customers within the organization, Kubernetes service concept can be used.

The application can be exposed on the Kubernetes worker node IP addresses for internal users to access directly.

External Customers

External customers who are outside the organization require a different approach.

A public IP address needs to be created for the application so that anyone in the world can access it.

Node Port Mode and Load Balancer Mode

This section explains node port mode and load balancer mode in Kubernetes services. It also mentions that detailed explanations of these modes can be found in previous videos.

Node Port Mode

In node port mode, an application is exposed on the node IP address.

The example provided uses MiniKube's node IP address as an illustration.

Load Balancer Mode

Load balancer mode is used when an application needs to be accessed by external customers.

A public IP address is created for this purpose so that everyone can access it globally.

Creating a Service in Kubernetes

This section demonstrates how to create a service in Kubernetes using YAML files. The speaker refers to examples from the official Kubernetes documentation.

Service Creation Steps

Create a YAML file for the service, e.g., service.yaml.

Ensure the selector in the service YAML matches the labels and selectors in the deployment or pod template.

The service will only look for pods with matching labels and selectors.

If unexpected pods with the same label are created, the service will forward traffic to them as well.

For more detailed explanations, refer to previous videos or official Kubernetes documentation.

Kubernetes Service Examples

This section highlights examples of Kubernetes services from the official Kubernetes documentation.

Node Port Example

In node port mode, an application is exposed on the node IP address.

The example provided demonstrates how to configure a service for node port mode using MiniKube's node IP address.

Refer to official Kubernetes documentation for more examples and details on different types of services.

New Section

The importance of copying the correct command and understanding target ports when creating a service in Kubernetes.

Copying the Correct Command

It is crucial to copy the correct command when working with Kubernetes.

Copying the wrong command can lead to problems with labels and selectors, making debugging difficult.

Understanding Target Ports

The Target Port is the port on which your application is running.

When creating a service, it is important to specify the correct Target Port.

In this case, the application is running on Port 8000, so that should be chosen as the Target Port.

New Section

Choosing node ports and understanding target ports in Kubernetes services.

Choosing Node Ports

When creating a service in Kubernetes, you can choose any node port you want.

In this example, 3007 is used as the node port number.

Understanding Target Ports (Continued)

The Target Port should be set to match the port on which your application is running.

In this case, since the application runs on Port 8000, that should be selected as the Target Port.

Saving and Applying Changes

After setting up the necessary configurations for the service, save them and apply them using kubectl apply -f service.yaml.

New Section

Checking information about services in Kubernetes using kubectl get svc.

Checking Service Information

To check information about services in Kubernetes, use kubectl get svc.

Adding -o yaml provides more detailed information about how traffic flows within the cluster.

New Section

Accessing applications through cluster IP or node IP addresses in Kubernetes services.

Cluster IP vs. Node IP Address

When creating a service in Kubernetes, it is assigned a Cluster IP address.

However, when using Node Port mode, the Cluster IP address is mapped to the Node IP address and a specific port.

Accessing Applications

To access the application using the Cluster IP address, use minikube ssh and copy the Cluster IP address.

Alternatively, you can access the application using the Node IP address and the specified port.

In this example, accessing http://<Node_IP>:3007/demo will route traffic to the application.

New Section

Reasons for not recommending direct access through Node IP addresses in Kubernetes services.

Service Creation in Kubernetes

When creating a service in Kubernetes, a Cluster IP is always assigned.

Additionally, when using Node Port mode, a port mapping is created to allow access through the Node IP address.

Not Recommended for Direct Access

Directly accessing applications through Node IP addresses is not recommended.

This is because Pod IPs already provide similar functionality.

Using Node Port mode exposes applications externally but limits accessibility from outside sources.

New Section

Understanding how cluster IPs and node ports work in Kubernetes services.

Importance of Cluster IPs

Cluster IPs are essential for accessing services within a Kubernetes cluster.

They provide internal routing between different components of an application.

Mapping Ports with Node IPs

When creating a service in Node Port mode, ports are mapped between the Cluster IP and the Node IP addresses.

This allows traffic to be routed correctly from external sources to pods running on specific nodes.

New Section

Demonstrating how to access applications using node IPs in Kubernetes services.

Obtaining Node IP Address

To obtain the node's IP address, use minikube ip or the IP address of an EC2 instance.

Accessing Applications

To access the application, use curl -L http://<Node_IP>:3007/demo.

The specific port used depends on the configuration of the service.

This allows direct access to the application running on a specific node.

New Section

Accessing applications from outside sources in Kubernetes services.

Accessing from Outside Sources

When accessing applications from outside sources, such as other people's browsers, use the load balancer IP address.

This ensures external traffic can reach the application.

Accessing from Local Machine

If accessing from your own laptop or local machine, you can use the Node IP address directly.

Since both your laptop and MiniKube are part of the same network, they can communicate without additional configurations.

New Section

Demonstrating how to access applications using node IPs in Kubernetes services through a browser.

Accessing Applications via Browser

To access applications through a browser, use the Node IP address and specified port.

In this example, accessing http://<Node_IP>:3007/demo will display the application in the browser.

New Section

Reasons why accessing applications may not work when accessed from outside sources.

Application Not Exposed

If an application is not exposed properly, it will not be accessible when accessed from outside sources.

This is because external traffic needs to be directed to the correct endpoint for successful access.

Modifying Service Type to Load Balancer

In this section, the speaker explains how to modify the service type from NodePort to LoadBalancer using kubectl. This change allows for load balancing of applications.

Modifying Service Type

Use kubectl edit svc command to edit the service.

Change the type from NodePort to LoadBalancer.

This modification will not work on Minikube, but it will work on cloud providers like AWS or Azure.

The external IP address will remain pending in Minikube, while cloud providers generate an IP address through their respective cloud control managers.

Exposing Applications with Load Balancer Type

The speaker discusses how load balancer type is supported only by cloud providers and explains how they generate an external IP address for services.

Generating External IP Address

Cloud control managers of AWS, Azure, and GCP generate the external IP address for services of type LoadBalancer.

In Minikube, a project called MetalLB can be used to expose applications and generate a public IP address. However, MetalLB is still in beta.

Understanding the concept of generating a public IP address is more important than trying out MetalLB.

Three Concepts of Services: Load Balancing, Service Discovery, and Exposing Applications

The speaker revisits the three concepts related to services: load balancing, service discovery, and exposing applications. They provide an overview of each concept discussed so far.

Three Concepts of Services

Load Balancing: Achieved by modifying the service type from NodePort to LoadBalancer. Allows distributing traffic across multiple pods.

Service Discovery: Demonstrated by modifying labels and selectors in a service. Shows that if labels and selectors are different, service discovery will not work.

Exposing Applications: Explained through the use of NodePort and LoadBalancer types to make applications accessible from outside the cluster.

Understanding Service Discovery

The speaker explains service discovery and demonstrates how modifying labels and selectors affects it.

Modifying Labels and Selectors

Use kubectl edit svc command to modify the selector in a service.

Changing the selector affects service discovery, as labels and selectors must match for pods to be detected by the service.

Demonstrated by modifying the selector and observing that the application becomes inaccessible.

Load Balancing in Kubernetes

In this section, the speaker explains the concept of load balancing in Kubernetes and demonstrates it using a tool called Cube Shark.

Installing Cube Shark

Cube Shark is a simple application that helps understand traffic flow within a Kubernetes cluster.

To install Cube Shark, refer to the Cube Shark documentation and follow the installation instructions.

Once installed, run the specified curl command or execute the provided commands for Mac users to start Cube Shark.

Access the Cube Shark browser on port 8899 to explore its features.

Load Balancing with Kubernetes Service

Load balancing is necessary when there are multiple replicas of an application and one replica cannot handle all requests.

By default, deployments or pods do not have load balancing. To enable load balancing, create a service in Kubernetes.

The speaker demonstrates load balancing by running a curl command multiple times and observing how requests are distributed among two pods.

Demonstrating Load Balancing with Cube Shark

The speaker runs a curl command six times to simulate requests being sent to the service.

Using Cube Shark, it can be observed that requests are distributed between two pods in a round-robin fashion.

The speaker explains that Kubernetes service performs load balancing by sending requests to different replicas based on their availability.

Troubleshooting Connection Issues with Cube Shark

In this section, the speaker encounters connection issues with Cube Shark and explains how they were resolved.

Connection Error with Cube Shark

The speaker encounters an error while proxying requests with Cube Shark: "error while proxying the request and context cancel."

To resolve this issue, the speaker restarts the connection between Cubeshark and their Kubernetes cluster using Cube sharp proxy command.

Restarting Connection with Cube sharp proxy

The Cube sharp proxy command is used to re-establish the connection between Cube Shark and the Kubernetes cluster.

The speaker demonstrates how to restart the connection, but mentions that detailed instructions will be provided in a separate video about Cube Shark.

Load Balancing Demonstration with Cube Shark (Continued)

In this section, the speaker continues demonstrating load balancing using Cube Shark after resolving the connection issues.

Observing Load Balancing

After restarting Cube Shark and sending six requests, it can be observed that requests are distributed between two pods in a round-robin fashion.

The speaker explains that Kubernetes service performs load balancing by sending requests to different replicas based on their availability.

This summary covers specific sections of the transcript related to load balancing and troubleshooting with Cube Shark.

New Section

In this section, the speaker explains the concept of the source and how it relates to executing commands from a browser or using the curl command. The speaker also demonstrates how to find the IP address of the source machine.

Understanding the Source

The source refers to the point where execution begins.

When executing commands from a browser or using the curl command, the source is typically the machine from which these commands are initiated.

To find the IP address of the source machine, use ifconfig and search for the desired IP address (e.g., 192.168.64.1).

New Section

This section focuses on explaining packet flow and introduces Cube shark as a tool for understanding packet travel.

Packet Flow and Cube Shark

After originating from the source machine, requests are sent to various destinations in a specific order.

In this case, after leaving the source machine with IP address 192.168.64.10, requests are sent to 172.170.1 (mini Cube IP address) and then to 170.170.7.

Cube shark is a tool that helps analyze packet flow in detail.

It allows users to replay actions, capture packets for debugging purposes, and gain insights into traffic patterns.

New Section

This section discusses additional tools like Wireshark and TCP dump that can be used for capturing and analyzing packets.

Additional Tools for Packet Analysis

Wireshark is another tool that can be used to capture packets and gain more detailed information about network traffic.

TCP dump is another useful tool for capturing packets and analyzing them based on TCP or HTTP requests.

These tools provide deeper insights into packet behavior, including layer 4 and layer 7 analysis.

While not covered in detail here, they are valuable resources for understanding network traffic patterns.

New Section

This section summarizes the concepts covered in the video, including load balancing, service discovery, and application exposure. The speaker also mentions Cube shark as a must-have tool for DevOps engineers.

Recap of Concepts

Load balancing: The video explained how requests are distributed across multiple instances of an application.

Service discovery: The process of locating available services within a network was demonstrated using both a browser and terminal commands.

Application exposure: The steps to expose an application were outlined.

Cube shark: A dedicated video will be created to explain this tool further. It is essential for understanding traffic flow in Kubernetes and provides features like service mapping and pod listing.

New Section

In this final section, the speaker concludes the video by encouraging viewers to like, provide feedback, and share it with others.

Conclusion

Cube shark is highlighted as a valuable tool for DevOps engineers to understand traffic patterns in Kubernetes.

Viewers are encouraged to like the video if they enjoyed it, provide feedback in the comment section, and share it with friends and colleagues.