Header Background Image

Linux container

CodiLime Glossary

Some common networking terms clearly explained

Glossary /L /

Linux container

Linux containers is a virtualization method that allows for sharing resources like CPU and memory without creating virtual machines. Linux Containers enable creating a separation layer between the operating system kernel and the application layer. Containers are widely used in the context of microservices architecture. Orchestration platforms like Kubernetes are used to manage containers. 

This solution does not contain an operating system (OS), binaries, or dependencies like those you’ll find in a standard VM setup. This feature makes them lightweight, portable and makes it possible to run them across numerous different environments, regardless of their configuration. 

What is LXC? 

LXC is a Linux container runtime with tools, library, templates and language bindings onboard. LXC facilitates creating and managing application containers and systems.

Components of LXC—the liblxc library, language bindings for the API, tools for controlling the containers, and distribution templates for the containers. 

Why use containers? 

  • container-based applications work efficiently in cloud environments, 
  • applications in containers are easy to scale, 
  • containers could be used as a deployment unit for microservices (and connected by network service mesh).

Read more:

Thumbnail of an article about Kubernetes: what is it and how you can use it (part 1/2)
CLOUD

Kubernetes: what is it and how you can use it (part 1/2)

Kubernetes is an open-source system for container orchestration enabling automated application deployment, scaling and management. Read this two-part blog post to understand the business perspective on Kubernetes. I will present a brief story of virtualization methods, the key concepts on which Kubernetes is built and how it can help your business when it comes to running containerized applications. The second part covers six main reasons to adopt Kubernetes. First, let’s take a look at the market data on the adoption of Kubernetes.
Thumbnail of an article about How to make your Kubernetes cluster secure
CLOUD

How to make your Kubernetes cluster secure

In the last couple of years Kubernetes (K8s) has become one of the most popular tools for running containerized applications. Many cloud companies, major ones among them, have adopted it to orchestrate their container-based workloads. Given its popularity, the problem of K8s security is becoming even more pressing. Read our two-part blog post series on how to make a Kubernetes cluster secure. Part one provides a brief history of virtualization, presents admission controllers and how they work and shows how Pod Security Policies, a powerful admission controller, can help you manage user actions on Kubernetes cluster.
Thumbnail of an article about Security in Kubernetes — overview of admission webhooks
CLOUD

Security in Kubernetes — overview of admission webhooks

This blog post is a continuation of two previous posts on security mechanisms in Kubernetes. If you have not yet read them, click here for part 1 and part 2 to see how you can provide an adequate level of security in Kubernetes deployments. Existing admission controllers are very useful, as they allow you to validate or modify requests to a Kubernetes API server. However, they have two limitations: They have to be compiled into an API server and can be configured only on the API server startup. The flexibility of admission webhooks helps solve these problems.Once enabled, their behavior depends on the special application running inside the Kubernetes cluster.
Thumbnail of an article about The benefits of Pod Security Policy — a use case
CLOUD

The benefits of Pod Security Policy — a use case

In the previous post I looked at how security is handled in Kubernetes. Let’s now see how it works in practice. One of the most powerful controllers is the Pod Security Policy admission controller (PSP). PSP is a cluster-level security mechanism that enables control over sensitive aspects of pod specification. It allows you to define a set of conditions a pod must meet in order to be accepted into the system.The following use case illustrates how it works. Let’s assume that we have a shared file system
Thumbnail of an article about Kubernetes workloads — using multiple networks
NETWORKS

Kubernetes workloads — using multiple networks

Since there is no separate networking object among Kubernetes objects enabling the running of multiple networks, a workaround is required. Using a Container Network Interface (CNI) is a good place to start. Read this blog post to learn how you can use it to get multiple networks for Kubernetes workloads. I also describe my proposal for changes in source code that will enable native handling of multiple networks in Kubernetes. This blog post is based on the presentation which Doug Smith from Red Hat and I gave at the KubeCon+CloudNativeCon North America 2019 conference.
Thumbnail of an article about Deploying a Kubernetes operator in OpenShift 4.x platform
CLOUD

Deploying a Kubernetes operator in OpenShift 4.x platform

Contrail-operator is a recently released open-source Kubernetes operator that implements Tungsten Fabricas a custom resource. Tungsten Fabric is an open-source Kubernetes-compatible, network virtualization solution for providing connectivity and security for virtual, containerized or bare-metal workloads. An operator needed to be adjusted to the OpenShift 4.x platform, which introduced numerous changes to its architecture compared with previous versions. In this blog post, you’ll read about three interesting use cases and their solutions.

Get your project estimate

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

For businesses that need support in their software or network engineering projects, please fill in the form and we’ll get back to you within one business day.

We guarantee 100% privacy.

Trusted by leaders:

Cisco Systems
Palo Alto Services
Equinix
Jupiter Networks
Nutanix