Difficulty: Advanced
Estimated Time: 20-30 minutes

Background

This lab focuses on understanding how a particular host actually runs the container images - from the deep internals of how containerized processes interact with the Linux kernel, to the docker daemon and how it receives REST API calls and translates them into system calls to tell the Linux kernel to create new containerized processes.

By the end of this lab you should be able to:

  • Understand the basic interactions of the major daemons and APIs in a typical container environment
  • Internalize the function of system calls and kernel namespaces
  • Understand how SELinux and sVirt secures containers
  • Command a conceptual understanding of how cgroups limit containers
  • Use SECCOMP to limit the system calls a container can make
  • Have a basic understanding of container storage and how it compares to normal Linux storage concepts
  • Gain a basic understanding of container networking and namespaces
  • Troubleshoot a basic Open vSwitch setup with Kubernetes/OpenShift

Outline

  • Daemons & APIs: Docker, Kubernetes Master, Node, and their interaction with the Linux kernel
  • System Calls & Kernel Namespaces: How they work inside of a container
  • SELinux & sVirt: Dynamically generated contexts to protect your containers
  • Cgroups: Dynamically created with container instantiation
  • SECCOMP: Limiting how a containerized process can interact with the kernel
  • Storage: How containers get local, copy on write storage
  • Pod Networking: How individual containers and pods connect to the network
  • Cluster Networking: How clusters of hosts manage the connections of containerized processes

Other Material

This video will give you a background to all of the concepts in this lab

Start Scenario

Once you have watched the background video, continue to the exercises

In this course you learned:

  • Understand the basic interactions of the major daemons and APIs in a typical container environment
  • Internalize the function of system calls and kernel namespaces
  • Understand how SELinux and sVirt secures containers
  • Command a conceptual understanding of how cgroups limit containers
  • Use SECCOMP to limit the system calls a container can make
  • Have a basic understanding of container storage and how it compares to normal Linux storage concepts
  • Gain a basic understanding of container networking and namespaces
  • Troubleshoot a basic Open vSwitch setup with Kubernetes/OpenShift

Other Material

Also, if you have any questions tweet us at:

@RedHat @OpenShift @CoreOS @fatherlinux

Don’t stop now! The next scenario will only take about 10 minutes to complete.

Linux Container Internals 2.0 - Lab 4: Container Host

Step 1 of 8

Daemons & APIs: Docker, Kubernetes Master, Node, and their interaction with the Linux kernel

The goal of this exercise is to gain a basic understanding of the APIs (Kubernetes/OpenShift, Docker, Linux kernel). First let's inspect the daemons which are running on the master nodes.

mega-proc.sh docker

Pay attention to the following proecesses and daemons running. You may notice that all of the docker commands and daemons have the "-current" extension - this is a methodology Red Hat uses to specify which version of the tools are installed. Red Hat supports two versions - a fast moving version with the -latest extension and a stable version targetted for OpenShift with the -current extension.

These processes all work together to create a container in the Linux kernel. The following is a basic description of their purpose:

  • dockerd: This is the main docker daemon. It handles all docker API calls (docker run, docker build, docker images) through either the unix socket /var/run/docker.sock or it can be configured to handle requests over TCP. This is the "main" daemon and it is started by systemd with the /usr/lib/systemd/system/docker.service unit file.
  • docker-containerd: Containerd was recently open sourced as a separate community project. The docker daemon talks to containerd when it needs to fire up a container. More and more plumbing is being added to containerd (such as storage).
  • docker-containerd-shim: this is a shim layer which starts the docker-runc-current command with the right options.
  • docker: This is the docker command which you typed on the command line.

Now let's take a look at the OpenShift daemons which are runnning on the master:

mega-proc.sh openshift

Pay particular attention the the following daemons. The OpenShift/Kubernetes code is very modular. OpenShift compiles all of the functionality into a single binary and determines which role the daemon will play with startup parameters. Depending on which installation method (single node, clustered, registry server only, manual) is chosen the OpenShift binaries can be started in different ways.

  • openshift start master api: This process handles all API calls with REST, kubectl, or oc commands.
  • /usr/bin/openshift start node: This process plays the role of the Kubelet and communicates with dockerd (which then communicates with the kernel) to create containers.
  • /usr/bin/openshift start master controllers: This daemon embeds the core control loops shipped with Kubernetes. A controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.

Now that you have an understanding of the different daemons, take a look at all of it together. Notice which daemons start which ones. Also, notice that the OpenShift API, Controller and Node processes are actually docker containers. There is roadmap to containerize the docker daemon on RHEL Atomic Host in the comming months as well.

ps aux --forest