Correlate Disparate Data Points

 

 

Correlate Disparate Data Points

Businesses and organizations can access vast amounts of data in today’s data-driven world. However, making sense of this data can be a challenging task. One effective way to gain valuable insights is by correlating disparate data points. We can unlock hidden knowledge and make informed decisions by finding connections and patterns between seemingly unrelated data. In this blog post, we will delve into the concept of correlating disparate data points and explore their significance in various fields.

Understanding Correlation:

Correlation refers to the statistical relationship between two or more variables. It allows us to determine if there is a connection between different data points and to what extent they influence each other. We can uncover meaningful insights and make predictions based on observed patterns by analyzing the correlation.

 

Highlights: Correlate Disparate Data Points

  • The Required Monitoring Solution

Digital transformation intensifies the touch between businesses, customers, and prospects. Although it expands the workflow agility, on the other hand, it introduces a significant level of complexity as it requires a more agile Information Technology (IT) architecture along with the increase in data correlation. This belittles the network and application visibility creating a substantial data volume and data points that require monitoring. The monitoring solution is required to correlate disparate data points.

The Role of Observability

SASE definition overcomes this by combining data points and offering them as a cloud solution that combines network security components into one coherent offering. The traditional monitoring use case can also be supplemented with the new Observability practices. To understand the differences between monitoring and Observability, in this recent post: Observability vs monitoring. All of which will improve network visibility.

 

Before you proceed, you may find the following posts helpful:

  1. Ansible Tower
  2. Network Stretch
  3. IPFIX Big Data
  4. Microservices Observability
  5. Software Defined Internet Exchange

 



Correlate Disparate Data Points.

Key Correlate Disparate Data Points Discussion points:


  • The rise of data and data points.

  • Technology transformation.

  • Growing data points and volumes.

  • Troubleshooting challenges.

  • A final note on econmic value.

 

Back to basics with Correlate Disparate Data Points

Data observability

Over the last while, data has transformed almost everything we do, starting as a strategic asset and evolving the core strategy. However, managing data quality is the most critical barrier for organizations to scale data strategies due to the need to identify and remediate issues appropriately. Therefore, we need an approach to quickly detect, troubleshoot, and prevent a wide range of data issues through data observability, a set of best practices that enable data teams to gain greater visibility of data and its usage.

Identifying Disparate Data Points:

Disparate data points refer to information that appears unrelated or disconnected at first glance. They can be derived from multiple sources, such as customer behavior, market trends, social media interactions, or environmental factors. The challenge lies in recognizing the potential relationships between these seemingly unrelated data points and understanding the value they can bring when combined.

Unveiling Hidden Patterns:

Correlating disparate data points reveals hidden patterns that would otherwise remain unnoticed. For example, in the retail industry, correlating sales data with weather patterns may help identify the impact of weather conditions on consumer behavior. Similarly, correlating customer feedback with product features can provide insights into areas for improvement or potential new product ideas.

Benefits in Various Fields:

The ability to correlate disparate data points has significant implications across different domains. Analyzing patient data alongside environmental factors in healthcare can help identify potential triggers for certain diseases or conditions. In finance, correlating market data with social media sentiment can provide valuable insights for investment decisions. In transportation, correlating traffic data with weather conditions can optimize route planning and improve efficiency.

Tools and Techniques:

Advanced data analysis techniques and tools are essential to correlate disparate data points effectively. Machine learning algorithms, data visualization tools, and statistical models can help identify correlations and patterns within complex datasets. Additionally, data integration and cleaning processes are crucial in ensuring accurate and reliable results.

Challenges and Considerations:

Correlating disparate data points is not without its challenges. Combining data from different sources often involves data quality issues, inconsistencies, and compatibility challenges. Additionally, ethical considerations regarding data privacy and security must be considered when working with sensitive information.

 

Getting Started: Correlate Disparate Data Points

Many businesses feel overwhelmed by the amount of data they’re collecting and don’t know what to do with it. The digital world swells the volume of data and data correlation to a business has access to. Apart from impacting the network and server resources, the staff is also taxed in their attempts to manually analyze the data while resolving the root cause of the application or network performance problem. Furthermore, IT teams operate in silos, making it difficult to process data from all the IT domains – this severely limits business velocity.

Digital Transformation

Diagram: Digital innovation and data correlation.

 

Data Correlation: Technology Transformation

Conventional systems, while easy to troubleshoot and manage, do not meet today’s requirements, which has led to introduction an array of new technologies. The technological transformation umbrella includes virtualization, hybrid cloud, hyper-convergence, and containers.

While technically remarkable, introducing these technologies posed an array of operationally complex monitoring tasks and increased the volume of data and the need to correlate disparate data points. Today’s infrastructures comprise complex technologies and architectures.

They entail a variety of sophisticated control planes consisting of next-generation routing and new principles such as software-defined networking (SDN), network function virtualization (NFV), service chaining, and virtualization solutions.

Virtualization and service chaining introduce new layers of complexity that don’t follow the traditional monitoring rules. Service chaining does not adhere to the standard packet forwarding paradigms, while virtualization hides layers of valuable information.

Micro-segmentation changes the security paradigm while introducing virtual machine (VM) mobility introduces north-to-south and east-to-west traffic trombones. The VM, which the application sits on, now has mobility requirements and may move instantly to different on-premise data center topology types or external to the hybrid cloud.

The hybrid cloud dissolves the traditional network perimeter and triggers disparate data points in multiple locations. Containers and microservices introduce a new wave of application complexity and data volume. Individual microservices require cross-communication, potentially located in geographically dispersed data centers.

All these waves of new technologies increase the number of data points and volume of data by an order of magnitude. Therefore, an IT organization must compute millions of data points to correlate information from business transactions to infrastructures such as invoices and orders.

 

Growing Data Points & Volumes

The need to correlate disparate data points

As part of the digital transformation, organizations are launching more applications. More applications require additional infrastructure. As a result, the infrastructure is always snowballing; therefore, the number of data points you need to monitor increases.

Breaking up a monolithic system into smaller, fine-grained microservices adds complexity when monitoring the system in production. With a monolithic application, we have well-known and prominent investigation starting points.

But the world of microservices introduces multiple data points to monitor, and it’s harder to pinpoint latency or other performance-related problems. The human capacity hasn’t changed – a human can correlate at most 100 data points per hour. The actual challenge surfaces because they are monitored in a silo.

Containers are deployed to run software that is found more reliable when moved from one computing environment to another, often used to increase business agility. However, the increase in agility comes at a high cost – containers will generate 18x more data than they would in traditional environments. Conventional systems may have a manageable set of data points to be managed, while a full-fledged container architecture could have millions.

secure digital transformation
Diagram: Secure digital transformation.

 

The amount of data to be correlated to support digital transformation far exceeds human capabilities. It’s just too much for the human brain to handle. Traditional monitoring methods are not prepared to meet the demands of what is known as “big data.” This is why some businesses use the big data analytics software from Kyligence.

That uses an AI-augmented engine to manage and optimize the data, allowing businesses to see their most valuable data. This helps businesses to make decisions. While data volumes grow to an unprecedented level, visibility is decreasing due to the complexity of the new application style and the underlying infrastructure. All this is compounded by ineffective troubleshooting and team collaboration.

 

Ineffective Troubleshooting Team Collaboration

The application rides on various complex infrastructures and, at some stage, require troubleshooting. There should be a science to troubleshooting, but most departments stay with the manual way. This causes challenges with cross-team collaboration upon an application troubleshooting event among multiple data center segments – network, storage, database, and application.

IT workflows are complex, and a single response/request query will touch all supporting infrastructure elements: routers, servers, storage, database, etc. For example, an application request may traverse the web front ends in one segment to be processed by database and storage modules on different segments. This may require firewalling or load-balancing services in different on and off-premise data centers.

IT departments will never have a single team overlooking all areas of the network, server, storage, database, and other infrastructure modules. The technical skill sets required are far too broad for any individual to handle efficiently.

Multiple technical teams are often distributed to support various technical skill levels at various locations, time zones, and cultures. Troubleshooting workflows between teams should be automated, although they are not because monitoring and troubleshooting are carried out in silos, completely lacking any data point correlation. The natural assumption is to add more people, which is nothing less than fueling the fire. An efficient monitoring solution is a winning formula.

There is an increasingly vast lack of collaboration due to silo boundaries that don’t even allow you to look at each other’s environments. By the design of the silos, engineers blame each other as collaboration is not built by the very nature of how different technical teams communicate.

Engineers say bluntly, “It’s not my problem; it’s not my environment.” In reality, no one knows how to drill down and pinpoint the root cause. Mean Time to Innocence becomes the de facto working practice when the application faces downtime. It’s all about how you can save yourself. Compounding application complexity, the lack of efficient collaboration and troubleshooting science creates a bleak picture.

 

How to Win the Race with Growing Volumes of Data and Data Volumes?

How do we resolve this mess and ensure the application meets the service level agreement (SLA) and operates at peak performance levels? The first thing you need to do is collect the data. Not just from one domain but all domains at the same time. Data must be collected from various data points from all infrastructure modules, no matter how complicated.

Once the data is collected, application flows are detected, and the application path is computed in real-time. The data is extracted from all data center points and correlated to determine the exact path and time. The path visually presents the correct application route and over what devices the application is traversing.

For example, the application path can instantly show application A flowing over a particular switch, router, firewall, load balancer, web frontend, and database server.

 

It’s An Application World

The application path defines what infrastructure components are being used and will change dynamically in today’s environment. The application that rides over the infrastructure uses every element in the data center, including interconnects to the cloud and other off-premise physical or virtual locations.

Customers are well informed about the products and services, as they have all the information at their fingertips. Thereby, it makes the work of applications complex to deliver excellent results. To comprehend the business’s top priorities and work towards them, having the right Objectives and Key Results (OKRs) is essential. You can review some examples of OKRs by Profit if you want to learn more about this topic.

That said, it is essential to note that an issue with critical application performance can happen in any compartment or domain on which the application depends. In a world that monitors everything but monitors in a silo, it’s difficult to understand the cause of the application problem quickly. The majority of time is spent isolating and identifying rather than fixing the problem.

Imagine a monitoring solution helping customers select the best coffee shop to order a cup from. The customer has a variety of coffee shops to choose from, and there are several lanes in each. One lane could be blocked due to a spillage, while the other could be slow due to a training cashier. Wouldn’t having all this information upfront before leaving your house be great?

 

Economic Value

Time is money in two ways. First is the cost, and the other is damage to the company brand due to poor application performance. Each device requires several essential data points to monitor. These data points contribute to determining the overall health of the infrastructure.

Fifteen data points aren’t too bad to monitor, but what about a million data points? These points must be observed and correlated across teams to conclude application performance. Unfortunately, the traditional monitoring approach in silos has a high time value. 

Using traditional monitoring methods and in the face of application downtime, the theory of elimination and answers are not easily placed in front of the engineer. There is a time value that creates a cost. Given the amount of data today, on average, it takes 4 hours to repair an outage, and an outage costs $300K.

If there is lost revenue, the cost to the enterprise, on average, is $5.6M. How much will it take, and what cost will a company incur if the amount of data increases 18x? A recent report states that only 21% of organizations can successfully troubleshoot within the first hour. That’s an expensive hour that could have been saved with the right monitoring solution.

There is real economic value in applying the correct monitoring solution to the problem and adequately correlating between silos. What if a solution does all the correlation? The time value is now shortened because, algorithmically, the system is carrying out the heavy-duty manual work for you.

Conclusion:

In a world inundated with data, correlating disparate data points is a powerful skill. By uncovering hidden patterns and connections, we can gain valuable insights and make informed decisions. Whether in business, healthcare, finance, or any other field, leveraging the potential of correlating disparate data points can lead to innovative solutions and improved outcomes. Embracing this approach can propel organizations forward and unlock new opportunities for growth and success.

 

Kubernetes PetSets

Kubernetes Networking 101

 

Kubernetes Networking 101

Kubernetes, an open-source container orchestration platform, has revolutionized how developers deploy and manage applications. As organizations increasingly adopt Kubernetes, understanding its networking capabilities becomes crucial for efficient container communication. This blog post will delve into Kubernetes networking, exploring its architecture, components, and critical concepts.

At its core, Kubernetes networking enables seamless communication between containers running on different nodes within a cluster. To achieve this, Kubernetes leverages a flexible and extensible networking model. The architecture comprises three main components: Pods, Services, and Ingress.

 

Highlights: Kubernetes Networking

  • The Kubernetes History

Kubernetes is an open-source cluster management tool released by Google in June 2014. Google has said it launches over 2 billion containers per week, and Kubernetes was designed to control and manage the orchestration of all these containers along with container networking. Initially, they built a Borg and Omega system, resulting in Kubernetes.

All lessons learned from Borg to Kubernetes are now passed to the open-source community. Kubernetes went 1.0 in July 2015 and is now at version 1.3.0. The Kubernetes deployment supports GCE, AWS, Azure, vSphere, and bare metal, and there are a variety of Kubernetes networking configuration parameters. Kubernetes forms the base for OpenShift networking

  • Kubernetes information check.

For additional information before you with Kubernetes networking 101, the post on Kubernetes chaos engineering discusses the need to stress and break a system, which is the only way to understand and optimize fully. Chaos Engineering starts with a baseline and introduces several controlled experiments. Then we have Kubernetes security best practice discuss the Kubernetes attack vectors and how to protect against them.

 

Before you proceed, you may find the following posts helpful:

  1. OpenShift SDN
  2. Docker Default Networking 101
  3. OVS Bridge
  4. Hands-On Kubernetes

 



Kubernetes Networking 101.

Key Kubernetes Networking 101 Discussion points:


  • Introduction to Kubernetes Networking.

  • Discussion of Microservices.

  • The challenges around network proximity.

  • Highlighting the Kubernetes Networking concepts.

  • Kubernetes Networking operation and traffic flow.

 

Introducing Kubernetes Networking

At a very high level, Kubernetes Networking 101 enables a group of hosts to be viewed as a single compute instance. The single compute instance, consisting of multiple physical hosts, is used to deploy containers. This offers an entirely different abstraction level to our single-container deployments.

Users start to think about high-level application services and the concept of service design only. They are no longer concerned with individual container deployment as the orchestrator looks after the deployment, scale, and management.

For example, if users specify to the orchestration system they want a specific type of application with defined requirements, now deploy it for me. The orchestrator manages the entire rollout, specifies the targeted hosts, and manages the container lifecycle. The user doesn’t get involved with host selection. This abstraction allows users to focus only on design and workload requirements – the orchestrator takes care of all the low-level deployment and management details.

Kubernetes Networking 101
Diagram: Kubernetes Networking 101

 

1. Pods:

Pods are the fundamental building blocks of Kubernetes, consisting of one or more containers that share a common network namespace. Each pod receives a unique IP address, allowing containers within the pod to communicate via localhost. However, communication between different pods requires additional networking components.

2. Services:

Services provide a stable and abstracted network endpoint to access a set of pods. By grouping pods based on a standard label, services ensure that applications can discover and communicate with each other seamlessly. Kubernetes offers four types of services: ClusterIP, NodePort, LoadBalancer, and ExternalName. Each service type caters to specific use cases, providing varying levels of accessibility.

3. Ingress:

Ingress is a Kubernetes resource that enables inbound connections to reach services within the cluster. It acts as a traffic controller, routing external requests to the appropriate service based on rules defined in the Ingress resource. Additionally, Ingress supports TLS termination, allowing secure communication with services.

Networking Concepts:

To comprehend Kubernetes networking fully, it is essential to grasp critical concepts that govern its behavior.

1. Cluster Networking:

Cluster networking refers to the communication between pods running on different nodes within a Kubernetes cluster. To establish node connectivity, Kubernetes leverages various networking solutions, such as overlay networks and software-defined networking (SDN). Popular SDN solutions include Calico, Flannel, and Weave.

2. DNS Resolution:

Kubernetes provides a built-in DNS service that enables easy discovery of services within the cluster. Each service is assigned a DNS name, which can be resolved to its corresponding IP address. This allows applications to communicate with services using their DNS names, enhancing flexibility and decoupling.

3. Network Policies:

Network policies define rules that dictate how pods communicate with each other. Administrators can enforce fine-grained access control and secure application traffic using network policies. Policies can be based on various criteria, such as IP addresses, ports, and protocols.

 

Microservices

Distributed systems are more fine-grained now, with Kubernetes driving microservices. Microservices is a fast-moving topic involving the breaking down applications into many specific services. All services have their lifecycles, collaborating. Splitting the Monolith with microservices is not a new idea ( the term is ), but the emergence of new technologies has a profound effect.

The specific domains/containers require constant communication and access to each other’s services. Therefore, a strategy needs to be maintained to manage container interaction. For example, how do we scale containers? What’s the process for container failure? How do we react to container resource limits? 

Although Docker does help with container management, Kubernetes orchestration works on a different scale and looks at the entire application stack allowing management at a service/application level.

We need a management and orchestration system to take full advantage of the portability of containers and microservices. Containers can’t just be thrown into a sea of computing and expect to tie themselves together and work efficiently.

A management tool is required to govern and manage the life of containers, where they are placed, and to whom they can talk. Containers have a complicated existence, and many pieces are used to patch up their communication flow and management. We have updates, high availability, service discovery, patching, security, and networking. 

The most important aspect to remember with Kubernetes or any content management system is that they are not concerned with individual container placement. Instead, the focus is on workload placement. Users enter high-level requirements, and the scheduler does the rest – where, when, and how many?

 

Kubernetes networking 101 and network proximity.

Looking at workloads to analyze placement optimizes application deployment. For example, some processes that are part of the same service will benefit from network proximity. Front-end tiers sending large chunks of data to a backend database tier should be close to each other, not trombone across the network Kubernetes host for processing.

Likewise, when common data needs to be accessed and processed, it makes sense to put containers “close” to each other in a cluster. The following diagram displays the core Kubernetes architecture.

 

Kubernetes Networking 101: The Constructs

Kubernetes uses four primary constructs to build the application stack – Pods, Services, Labels, and Replication Controllers. All constructs are configured and combined, resulting in a complete application stack with all management components—pods group similar containers on the same hosts.

Labels tag objects; replication controllers manage the desired state at a POD level, not container level and services enable Pod-to-Pod communication. These constructs enable the management of your entire application lifecycle instead of individual application components. Construct definition is through configuration files either in YAML or JSON format.

 

The Kubernetes Pod

Pods are the smallest scheduling unit in Kubernetes and hold a set of closely related containers, all sharing fate and resources. Containers in a Pod share the same Kubernetes network namespace and must be installed on the same host. The main idea of keeping similar or related containers together is that processing is performed locally and does not incur any latency traversing from one physical host to another. As a result, local processing is always faster than remote processing. 

Pods essentially hold containers with related pieces of the application stack. The critical point is that they are ephemeral and follow a specific lifecycle. They should come and go without service interruption as any service-destined traffic directed should be towards the “service” endpoint IP address, not the Pod IP address.

Even Though Pods have a pod-wide-IP address, service reachability is carried out with service endpoints. Services are not as ephemeral ( although they can be deleted ) and don’t go away as much as Pods. They act as the front-end VIP to back-end Pods ( more on later ). This type of architecture hammers home the level of abstraction Kubernetes seeks.

 

Pod definition file

The following example displays a Pod definition file. We have basic configuration parameters, such as the Pod’s name and ID. Also, notice that the object type is set to “Pod.” This will be set according to the object we are defining. Later we will see this set as “service” for defining a service endpoint.

In this example, we define two containers – “testpod80” and “testpod8080”. We also have the option to specify the container image and Label. As Kubernetes assigns the same IP to the Pod where both containers live, we should be able to browse to the same IP but different port numbers, 80 or 8080. Traffic gets redirected to the respective container.

 

Kubernetes Pod

Kubernetes labels

Containers within a Pod share their network namespaces. All containers within can reach each other’s ports on localhost. This reduces the isolation between containers, but any more isolation would go against why we have Pods in the first place. They are meant to group “similar” containers sharing the same resource volumes, RAM, and CPU. For Pod segmentation, we have labels – a Kubernetes tagging system.

Labels offer another level of abstraction by tagging items as a group. They are essentially key-value pairs categorizing constructs. When we create Kubernetes constructs, we can set a label, which acts as a tag for that construct.

This means you can access a group of objects by specifying the label assigned to those objects. For example, labels distinguish containers as part of a web or database tier. The “selector” field tells Kubernetes which labels to use in finding Pods to forward traffic to.

 

Replication Controller

Container Scheduler

The replication controller ( RC ) manages the lifecycle and state of Pods. It ensures the desired state always matches the actual state. When you create an RC, you define how many copies ( aka replicas) of the Pod you want in the cluster.

The RC maintains that the correct numbers are running by creating or removing Pods at any time. Kubernetes doesn’t care about the number of containers running in a Pod; its only concern is the number of Pods. Therefore, it works at a Pod level.

The following is an example of an RC service definition file. Here you can see that the desired state of replicas is “2”. The replica of 2 means that the number of pods each controller should maintain is 2. Changing the number up or down will either increase or decrease the number of Pods the replication controller manages.

For example, if the RC notices too many, it will stop some from returning the replication controller to the desired state. The RC keeps track of the desired state and returns it to the state specified in the service definition file. We may also assign a label for grouping replication controllers.

 

Kubernetes replication controller

 

Kubernetes Services

Service endpoints enable the abstraction of services and the ability to scale horizontally. Essentially, it is an abstraction defining a logical set of Pods. Services represent groups of Pods acting as one, allowing Pods to access services in other Pods without directing service-destined traffic to the Pod IP. Remember, Pods are short-lived!

The service endpoint’s IP address is from the “Portal Net” range defined on the API service. The address is local to the host, so make sure it doesn’t clash with the docker0 bridge IP address.

Pods are targeted by accessing a service that represents a group of Pods. A service can be viewed with a similar analogy to a load balancer, sitting in front of Pods accepting front-end service-destined traffic. Services act as the main hooking point for service / Pod interactions. They offer high-level abstraction to Pods and the containers within.

All traffic gets redirected to the service IP endpoint, which performs the redirection to the correct backend. Traffic hits the service IP address ( Portal Net ), and a Netfilter IPtable rules forward to a local host high port number.

The -proxy service creates the high port number forming the basis for load balancing. The load balancing object then listens to that port. The Kub proxy acts as a full proxy, maintaining two different TCP connections.

One separates the connection from the container to the proxy and another from the proxy to the load-balanced destination. The following is an example of a service definition file. The service listens on port 80 and sends traffic to the backend container port on 8080. Notice how the object kind is set to “service” and not “Pods” like in the previous definition file.

 

Kubernetes Services

Kubernetes Networking 101 Model

The Kubernetes networking model details that each Pod should have a routable IP address. This makes communication between Pods easier by not requiring any NAT or port mappings we had with earlier versions of Docker networking.

With Kubernetes, for example, we can have a web server and database server placed in the same Pod and use the local interface for cross-communication. Furthermore, as there is no additional translation, performance is better than a NAT’d approach.

 

Kubernetes network proxy

Kubernetes fulfills service -> Pods integration by enabling a network proxy called the Kube-proxy on every node in a cluster. The network proxy is always there even if Pods are not running. Its main task is to route traffic to the correct Pod and can do TCP, UDP stream forwarding or round robin TCP, UDP forwarding.

The Kube-proxy captures service-destination traffic and proxies requests from the service endpoint back to the application’s Pod. The traffic is forwarded to the Pods on the target port defined in the definition file. The target port is a random port assigned during service creation.

To make all this work, Kubernetes uses IPtables and Virtual IP addresses.

When using Kubernetes alongside, for example, Opencontrail, the Kube-proxy is disabled on all hosts, and the OpenContrail router module implements connectivity via overlays ( MPLS over UDP encapsulation ). Another vendor on the forefront is Midokura, the co-founder behind OpenStack Project Kuryr. This project aims to bring any SDN plugin (MidoNet, Dragon flow, OVS, etc.) to Containers—more on these another time.

 

Kubernetes Pod-IP approach

The Pods IP address is reachable by all other Pods and hosts in the Kubernetes cluster. The address is not usually routable outside of the cluster. This should not be too much of a concern as most traffic stays within application tiers inside the cluster. Mapping external load-balancers achieve any inbound external traffic to services in the cluster.

The Pod-IP approach assumes that all Pods can reach each other without creating specific links. They can access each other by IP rather than through a port mapping on the physical host. Port mappings hide the original address by performing a masquerade – Source NAT.

Similar to how your home residential router hides local PC and laptop IP addresses from the public Internet. Cross-node communication is much simpler as every Pod has an IP address. There isn’t any port mapping or NAT like there is with default docker networking. If the Kube-proxy receives traffic for a Pod, not on its host, it simply forwards the traffic to the correct Pod-IP for that service.

The IP per POD offers a simplified approach to K8 networking. A unique IP per host would potentially need port mappings on the host IP as the number of containers increases. Managing port assignment would become an operational and management burden, similar to earlier versions of Docker. Conversely, a unique IP per container would surely hit scalability limits.

 

Kubernetes PAUSE container

Kubernetes has what’s known as a PAUSE container, also referred to as a Pod infrastructure container. It handles the networking by holding the networking namespace and IP address for the containers on that Pod. Some refer to the PAUSE container as an implementation detail you can safely ignore.

Each container uses a Pod’s “mapped container” mode to connect to the pause container. The mapped container mode is implemented with a source and target container grouping. The source container is the user-created container, and the target container is the infrastructure pause container.

Destination Pod IP traffic first lands on the pause container and gets translated to the backend containers. The pause container and the user-built containers all share the same network stack. Remember we created a service destination file with two containers – port 80 and port 8080? It is the pause container that listens on these port numbers.

In summary, the Kubernetes model introduces three methods of communication.

  • a) Pod-to-Pod communication directly by IP address. Kubernetes has a Pod-IP-wide metric simplifying communication.
  • b) Pod-to-Service Communication – Clients’ traffic is directed to the virtual service IP, which is then intercepted by the kub-proxy process ( running on all hosts) and directed to the correct Pod.
  • c) External-to-Internal Communication – external access is captured by an external load balancer that targets nodes in a cluster. The Kub proxy determines the correct Pod to send traffic to—more on this in a separate post.

 

Docker & Kubernetes networking comparison

Docker uses host-private networking. The Docker engine creates a default bridge, and every container gets a virtual ethernet to that bridge. The veth acts like a pipe – one end is mapped to the docker0 bridge namespace and the other to the container’s Linux namespace. This provides connectivity between containers on the same Docker bridge.

All containers are assigned an address from the 172.17.42.0 range and 172.17.42.1 to the default bridge acting as the container gateway. Any off-host traffic requires port mappings and NAT for communication. Therefore, the container’s IP address is hidden, and the network would see the container traffic coming from the docker nodes’ physical IP address. 

The effect is that containers can only talk to each other by IP address on the same virtual bridge. Any off-host container communication requires messy port allocations. Recently, there have been enhancements to docker networking and multi-host native connectivity without translations. Although there are enhancements to the Docker network, the NAT / Port mapping design is not a clean solution.

The K8 model offers a different approach, and the docker0 bridge gets a routable IP address. Any outside host can access that Pod by IP address rather than through a port mapping on the physical host. Kubernetes has no NAT for container-to-container or container-to-node traffic.

 

Conclusion:

Understanding Kubernetes networking is crucial for building scalable and resilient applications within a containerized environment. By leveraging its flexible architecture and components like Pods, Services, and Ingress, developers can enable seamless container communication and ensure efficient network management. Moreover, comprehending network concepts like cluster networking, DNS resolution, and network policies empowers administrators to establish robust and secure communication channels within the Kubernetes ecosystem. Embracing Kubernetes networking capabilities unlocks the full potential of this powerful container orchestration platform.

 

Docker Container Diagram

Container Based Virtualization

 

 

Container Based Virtualization

Container-based virtualization, or containerization, is a popular technology revolutionizing how we deploy and manage applications. In this blog post, we will explore what container-based virtualization is, why it is gaining traction, and how it differs from traditional virtualization techniques.

Container-based virtualization is a lightweight alternative to traditional methods such as hypervisor-based virtualization. Unlike virtual machines (VMs), which require a separate operating system (OS) instance for each application, containers share the host OS. This means containers can be more efficient regarding resource utilization and faster to start and stop.

 

Highlights: Container Based Virtualization

  • Traditional Deployment Models

So how do containers facilitate virtualization? Firstly, the traditional application deployment was based on a single-server approach. As a result, one application was installed per physical server, wasting server resources, and components such as RAM and CPU were never fully utilized. There was also considerable vendor lock-in, making moving applications from one hardware vendor to another hard.

Then, the world of hypervisor-based virtualization was introduced, and the concept of a virtual machine (VM) was born. Soon after, we had container-based applications. Container-based virtualization introduced container networking, and new principles arose for security around containers, specifically, Docker container security.

  • Introducing hypervisors

We still deployed physical servers but introduced hypervisors on the physical host, enabling the installation of multiple VMs on a single server. Each VM is isolated from its operating system. Hypervisor-based virtualization introduced better resource pooling as one physical server could now be divided into multiple VMs, each hosting a different application type. This was years better than single-server deployments and opened the doors to open networking. 

The VM deployment approach increased agility and scalability as applications within a VM are scaled by simply spinning up more VMs on any physical host. While hypervisor-based virtualization was a step in the right direction, a guest operating system for each application is pretty intensive. Each VM requires RAM, CPU, storage, and an entire guest OS. All of which consume resources.

  • Introducing Virtualization

Another advantage of virtualization is the ability to isolate applications or services. Each virtual machine operates independently, with its resources and configurations. This enhances security and stability, as issues in one virtual machine do not affect others. It also allows for easy testing and development, as virtual machines can be quickly created and discarded.

Virtualization also offers improved disaster recovery and business continuity. By encapsulating the entire virtual machine, including its operating system, applications, and data, into a single file, organizations can quickly back up, replicate, and restore virtual machines. This ensures that critical systems and data are protected and can be quickly recovered during a failure or disaster.

Furthermore, virtualization enables workload balancing and dynamic resource allocation. Virtual machines can be dynamically migrated between physical servers to optimize resource utilization and performance. This allows for better utilization of computing resources and the ability to respond to changing workload demands.

 

You may find the following helpful post before proceeding to how containers facilitate virtualization.

  1. Docker Default Networking 101
  2.  Kubernetes Networking 101
  3. Kubernetes Network Namespace
  4. WAN Virtualization
  5. OVS Bridge
  6. Remote Browser Isolation

 



Container Virtualization.

Key Container Based Virtualization Discussion points:


  • Introduction to containerized technologies.

  • The role of container based applications.

  • Discussion on container networking and Linux kernel. 

  • A final note on microsegmentation.

 

  • A key point – Video 1: Video on hypervisor-based virtualization

The hypervisor allows multiple operating systems to share a single physical host enabling multiple container-based applications on one physical host. Many call the hypervisor a simple software or lightweight operating system running on a host. However, its attack surface is far more significant than a normal O/S as it could hold hundreds of virtual machines running their independent OS and application set, all having the potential for compromise.

 

Technology Brief : Cloud Security - Hypervisor Vulnerabilities
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Back to Basics: Containers and Container Virtualization

The Traditional World

Before we address how containers facilitate virtualization, let’s address the basics. In the past, we could solely run one application per server. However, the open-systems world of Windows and Linux didn’t have the technologies to safely and securely run multiple applications on the same server.

So every time we needed a new application, we would buy a new server. We had the virtual machine (VM) to solve the waste of resources. With the VM, we had a technology that permitted us to safely and securely run applications on a single server. But, unfortunately, the VM model has additional challenges too.

Migrating VMs

For example, VMs are slow to boot, and portability isn’t great — migrating and moving VM workloads between hypervisors and cloud platforms is more complicated than it needs to be. All of which drove the need for a new technology of containers with container virtualization.

How do containers facilitate virtualization? So, we needed a lightweight tool without losing the scalability and agility benefits of the VM-based application approach. The lightweight tool is container-based virtualization, and Docker acts at the forefront. The container offers a similar capability to that of object-oriented programming. They let you build composable modular building blocks, making it easier to design distributed systems.

Docker Container Diagram
Diagram: Docker Container. Source Docker.

 

  • A key point: Lab Guide on Container Networking

In the following example, we have one docker host. We can list the available networks to these docker hosts with the command docker network ls. These are not WAN or VPN networks; these are only docker networks.

Docker networks are virtual networks allowing containers to communicate with each other and the outside world. They provide isolation, security, and flexibility to manage network traffic flow between containers. By default, when you create a new Docker container, it is connected to a default bridge network, which allows communication with other containers on the same host.

Notice the subnets assigned of 172.17.0.0/16. So the default gateway ( exit point) is set to the docker0 bridge.

Docker networking
Diagram: Docker networking

Types of Docker Networks:

Docker offers various types of networks, each serving a specific purpose:

1. Bridge Network:

The bridge network is the default network that enables communication between containers on the same host. Containers connected to the bridge network can communicate using IP addresses or container names. It provides a simple way to connect containers without exposing them to the outside world.

2. Host Network:

In the host network mode, a container shares the network stack with the host, using its network interface directly. This mode provides maximum network performance as no network address translation (NAT) is involved. However, it also means the container is directly exposed to the host’s network, potentially introducing security risks.

3. Overlay Network:

The overlay network allows containers to communicate across multiple Docker hosts, even in different physical or virtual networks. It achieves this by encapsulating network packets and routing them to the appropriate destination. Overlay networks are essential for creating distributed and scalable applications.

4. Macvlan Network:

The Macvlan network mode allows containers to have MAC addresses and appear as separate devices. This mode is useful when assigning IP addresses to containers and making them accessible from the external network. It is commonly used when containers must be treated as physical devices.

5. None Network:

The none network mode isolates a container from all networking. It effectively disables all networking capabilities and prevents the container from communicating with other containers or the outside world. This mode is typically used when networking is not required or desired.

  • A key point: Lab Guide on Container Networking

You can attach as many containers to a bridge. They will be assigned IP addresses within the same subnet, meaning they can communicate by default. You can have a container with two Ethernet interfaces ( virtual interfaces ) connected to two different bridges on the same host and have connectivity to two networks simultaneously.

Also, remember that the scope is local when you are doing this, and even if the docker hosts are on the same underlying network but with different hosts, they won’t have IP reachability. In this case, you may need a VXLAN overlay network to connect containers on different docker hosts together.

inspecting container networks
Diagram: Inspecting container networks

Container-based Virtualization

One of the critical benefits of container-based virtualization is its portability. Containers encapsulate the application and all its dependencies, allowing it to run consistently across different environments, from development to production. This portability eliminates the “it works on my machine” problem and makes it easier to maintain and scale applications.

Scalability

Another advantage of containerization is its scalability. Containers can be easily replicated and distributed across multiple hosts, making it straightforward to scale applications horizontally. Furthermore, container orchestration platforms, like Kubernetes, provide automated management and scaling of containers, simplifying the deployment and management of complex applications.

Security

Security is crucial to any virtualization technology, and container-based virtualization is no exception. Containers provide isolation between applications, preventing them from interfering with each other. However, it is essential to note that containers share the same kernel as the host OS, which means a compromised container can potentially impact other containers. Proper security measures, such as regular updates and vulnerability scanning, are essential to ensure the security of containerized applications.

Tooling

Container-based virtualization also offers various tools and platforms for application development and deployment. Docker, for example, is a popular containerization platform that provides a user-friendly interface for building, running, and managing containers. It simplifies container image creation and enables developers to package their applications and dependencies.

Applications of Container-Based Virtualization:

1. DevOps and Continuous Integration/Continuous Deployment (CI/CD): Containerization enables developers to package applications, libraries, and configurations into portable and reproducible containers. This simplifies the deployment process and ensures consistency across different environments, facilitating faster software delivery.

2. Microservices Architecture: Container-based virtualization aligns well with the microservices architectural pattern. Organizations can develop, deploy, and scale each service independently using containers by breaking down complex applications into more minor, loosely coupled services. This approach enhances modularity, scalability, and fault tolerance.

3. Hybrid Cloud and Multi-Cloud Environments: Containers provide a unified platform for deploying applications across hybrid and multi-cloud environments. With container orchestration tools, organizations can leverage the benefits of multiple cloud providers while ensuring consistent deployment and management practices.

 

Application Landscape Changes

The application landscape has changed from a monolithic design to a design consisting of microservices. Today applications are constantly developed. Patches usually patch only certain parts of the application, and the entire application is built from loosely coupled components instead of existing tightly coupled ones.

The entire application stack is broken into components and spread over multiple servers and locations, all requiring cross-communication.

For example, users connect to a presentation layer, the presentation layer then connects to some shopping cart, and the shopping cart connects to a catalog library. These components are potentially stored on different servers, maybe different data centers.

The application is built from several small parts, and these tiny parts are known as microservices. Each component or microservice can now be put into a lightweight container – a scaled-down VM. 

container based virtualization
Diagram: Container based virtualization.

 

How do containers facilitate virtualization?

  • Container Based Applications

Now, we have complex distributed software stacks based on microservices. Its base consists of loosely coupled components that may change and software that runs on various hardware, including test machines, in-house clusters, cloud deployments, etc. The web front end may include the following:

  • Ruby + Rail.
  • API endpoints with Python 2.7.
  • Stack website with Nginx.
  • A variety of databases.

We have a very complex stack on top of various hardware devices. While the traditional monolithic application will likely remain for some time, containers still exhibit the use case to modernize the operational model for conventional stacks. Both monolithic and container-based applications can live together.

 

Container based virtualization

The application’s complexity, scalability, and agility requirements have led us to the market of container-based virtualization. Container-based virtualization uses the host’s kernel to run multiple guest instances. Now, we can run multiple guest instances (containers), and each container will have its root file system, process, and network stack.

Containers allow you to package up an application with all its parts in an isolated environment. It is a complete abstraction and does not need to run dependencies on the hosts. Docker, a type of container (first based on Linux Containers but now powered by runC), separates the application from infrastructure using container technologies. 

Similar to how VMs separates the operating system from bare metal. It lets you build a layer of isolation in software that reduces the burden of human communication and specific workflows. An excellent way to understand containers is to accept that they are not VMs – they are simple wrappers around a single Unix process. Containers contain everything they need to run (runtime, code, libraries, etc.).

 

Linux kernel namespaces

Isolation or variants of isolation have been around for a while. We have mount namespacing in 2.4 kernels and userspace namespacing in 3.8. These technologies allow the kernel to create partitions and isolate PIDs. Linux containers (Lxc) started in 2008, and Docker was introduced in Jan 2013, with a public release of 1.0 in 2014. We are now at version 1.9, which has some new networking enhancements.

Docker uses Linux kernel namespaces and control groups, providing an isolated workspace, which offers the starting grounds for the Docker security options. Namespaces offer an isolated workspace that we call a container. They help us fool the container.

We have PID for process isolation, MOUNT for storage isolation, and NET for network-level isolation. The Linux network subsystem has the correct information for additional Linux network information.

 

how do containers facilitate virtualization
Diagram: How do containers facilitate virtualization

 

Container based application: Container operations

Containers use schedulers. The task of a scheduler is to start containers on the correct host and then connect them. In addition, it needs to manage container failover and handle container scalability when there is too much data to process for a single instance. Popular container schedulers include Docker Swarm, Apache Mesos, and Google Kubernetes.

The selection of the correct host depends on the type of scheduler used. For example, Docker Swarm will have three strategies – spread, binpack, and random. Spread means node selection is based on the fewest containers, disregarding their states. Binpack selection is based on hosts with minimum resources, i.e., most packed. Finally, random strategy selections are chosen randomly.

 

Containers are quick to start.

How do containers facilitate virtualization? First, they are quick. Starting a container is much faster than starting a VM – lightweight containers can be started as low as 300ms. Initial tests on Docker revealed that a newly created container from an existing image takes up only 12 kilobytes of disk space.

A VM could take up thousands of megabytes. The container is lightweight as they are just referenced points to a layered filesystem image. Container deployment is also swift and network efficient.

Fewer data needs to travel across the network and storage fabrics. Elastic applications that have frequent state changes can be built more efficiently. Both Docker and Linux containers fundamentally change application consumption. 

As a side note, not all workloads are suitable for containers, and to support multi-cloud environments, heavy loads like databases are put into VMs. 

 

Docker networking

Docker networking is an essential aspect of containerization that allows containers to communicate with each other and external networks. In this document, we will explore the different networking options available in Docker and how they can facilitate seamless communication between containers.

By default, Docker provides three networking options: bridge, host, and none. The bridge network is the default network created when Docker is installed. It allows containers to communicate with each other using IP addresses. Containers within the same bridge network can communicate with each other directly without the need for port mapping.

As the name suggests, the host network allows containers to share the network namespace with the host system. This means that containers using the host network can directly access the network interfaces of the host system. This option is helpful for scenarios where containers must bind to specific network interfaces on the host.

On the other hand, the none network option completely isolates the container from the network. Containers using the none network cannot communicate with other containers or external networks. This option is useful when running a container in complete isolation.

 

Creating custom networks

In addition to these default networking options, Docker also provides the ability to create custom networks. Custom networks allow containers to communicate with each other, even if they are not in the same network namespace. Custom networks can be created using the `docker network create` command, specifying the desired driver (bridge, overlay, macvlan, etc.) and any additional options.

One of the main benefits of using custom networks is the ability to define network-level access control. Docker provides the ability to define network policies using network labels. These labels can control which containers can communicate with each other and which ports are accessible.

 

  • A key point – Video 2: Docker containers and Docker networking.

In this video, we will go through some basics of containers. The building blocks of containers are namespaces and control groups. However, they share the host kernel, which is a security concern. We will also address container orchestrators with Kubernetes and discuss PODs, Services, NAT, and VXLAN.

Highlighting Docker Containers
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Summary of Docker networking

Networking is very different in Docker than what we are used to. Networks are domains that interconnect sets of containers. So, if you give access to a network, you can access all containers. You must specify rules and port mapping if you want external access to other networks or containers.

A driver backs every network, be it a bridge or overlay driver. These Docker-based drivers can be swapped out with any ecosystem driver. The team at Docker views them as pluggable batteries.

Docker utilizes the concept of scope – Local (default) and Global. The local scope is a local network, and the global scope has visibility across the entire cluster. If your driver is a global scope driver, your network belongs to a global scope. Local scope driver corresponds to local scope.

 

Containers and Microsegmentation

Microsegmentation is a security technique that divides a network into smaller, isolated segments, allowing organizations to create granular security policies. This approach provides enhanced control and visibility over network traffic, preventing lateral movement and limiting the impact of potential security breaches.

Microsegmentation offers organizations a proactive approach to network security, allowing them to create an environment more resilient to cyber threats. By implementing microsegmentation, organizations can enhance their security posture, minimize the risk of lateral movement, and protect their most critical assets. As the cyber threat landscape continues to evolve, microsegmentation is an effective strategy to safeguard network infrastructure in an increasingly interconnected world.

  • Docker and Micro-segmentation

Docker 0 is the default bridge. They have now extended into bundles of multiple networks, each with independent bridges. Different bridges cannot directly talk to each other. It is a private, isolated network offering micro-segmentation and multi-tenancy features.

The only way for them to communicate is via host namespace and port mapping that is administratively controlled. Docker multi-host networking is a new feature in 1.9. A multi-host network comprises several docker hosts that form a cluster.

Several containers in each host form the cluster by pointing to the same KV (example -zookeeper) store. The KV store that you point to is the one that defines your cluster. Multi-host networking enables the creation of different topologies and lets the container belong to several networks. The KV store may also be another container, allowing you to stay in a 100% container world.

 

Final points on container based virtualization

In recent years, container-based virtualization has become famous for deploying and managing applications. Unlike traditional virtualization, which relies on hypervisors to run multiple virtual machines on a single physical server, container-based virtualization leverages lightweight, isolated containers to run applications.

So, what exactly is container-based virtualization, and why is it gaining traction in the technology industry? In this blog post, we will explore the concept of container-based virtualization, its benefits, and how it differs from traditional virtualization.

 

Operating system-level virtualization

Container-based virtualization, also known as operating system-level virtualization, is a form of virtualization that allows multiple containers to run on a single operating system kernel. Each container is isolated from the others, ensuring that applications and their dependencies are encapsulated within their runtime environment. This isolation eliminates application conflicts and provides a consistent environment across deployment platforms.

Docker default networking 101
Diagram: Docker default networking 101

Critical advantages of container virtualization

One of the critical advantages of container-based virtualization is its lightweight nature. Containers are designed to be portable and efficient, allowing for rapid deployment and scaling of applications. Unlike virtual machines, which require an entire operating system to run, containers share the host operating system kernel, reducing resource overhead and improving performance.

Another benefit of container-based virtualization is its ability to facilitate microservices architecture. By breaking down applications into more minor, independent services, containers enable developers to build and deploy applications more efficiently. Each microservice can be encapsulated within its container, making it easier to manage and update without impacting other application parts.

 

Greater flexibility and scalability

Moreover, container-based virtualization offers greater flexibility and scalability. Containers can be easily replicated and distributed across hosts, allowing for seamless horizontal scaling. This ability to scale quickly and efficiently makes container-based virtualization ideal for modern, dynamic environments where applications must adapt to changing demands.

Container virtualization is not a complete replacement.

It’s important to note that container-based virtualization is not a replacement for traditional virtualization. Instead, it complements it. While traditional virtualization is well-suited for running multiple operating systems on a single physical server, container-based virtualization is focused on maximizing resource utilization within a single operating system.

In conclusion, container-based virtualization has revolutionized how applications are deployed and managed. Its lightweight nature, isolation capabilities, and scalability make it a compelling choice for modern software development and deployment. As technology continues to evolve, container-based virtualization will likely play a significant role in shaping the future of application deployment.

Container-based virtualization has transformed how we develop, deploy, and manage applications. Its lightweight nature, scalability, portability, and isolation capabilities make it an attractive choice for modern software development. By adopting containerization, organizations can achieve greater efficiency, agility, and cost savings in their software development and deployment processes. As container technologies continue to evolve, we can expect even more exciting possibilities in virtualization.

 

how do containers facilitate virtualization