The basic units of OKD applications are called containers. Linux container technologies are lightweight mechanisms for isolating running processes so that they are limited to interacting with only their designated resources.
Many application instances can be running in containers on a single host without visibility into each others' processes, files, network, and so on. Typically, each container provides a single service (often called a "micro-service"), such as a web server or a database, though containers can be used for arbitrary workloads.
The Linux kernel has been incorporating capabilities for container technologies for years. More recently the Docker project has developed a convenient management interface for Linux containers on a host. OKD and Kubernetes add the ability to orchestrate Docker-formatted containers across multi-host installations.
Though you do not directly interact with the Docker CLI or service when using OKD, understanding their capabilities and terminology is important for understanding their role in OKD and how your applications function inside of containers. The docker RPM is available as part of RHEL 7, as well as CentOS and Fedora, so you can experiment with it separately from OKD. Refer to the article Get Started with Docker Formatted Container Images on Red Hat Systems for a guided introduction.
Init containers are a Technology Preview feature only.
A pod can have init containers in addition to application containers. Init containers allow you to reorganize setup scripts and binding code. An init container differs from a regular container in that it always runs to completion. Each init container must complete successfully before the next one is started.
Containers in OKD are based on Docker-formatted container images. An image is a binary that includes all of the requirements for running a single container, as well as metadata describing its needs and capabilities.
You can think of it as a packaging technology. Containers only have access to resources defined in the image unless you give the container additional access when creating it. By deploying the same image in multiple containers across multiple hosts and load balancing between them, OKD can provide redundancy and horizontal scaling for a service packaged into an image.
You can use the Docker CLI directly to build images, but OKD also supplies builder images that assist with creating new images by adding your code or configuration to existing images.
Because applications develop over time, a single image name can actually
refer to many different versions of the "same" image. Each different
image is referred to uniquely by its hash (a long hexadecimal number
fd44297e2ddb050ec4f…) which is usually shortened to 12
Rather than version numbers, the Docker service allows applying tags (such as
GA, or the default
latest) in addition to the image name to
further specify the image desired, so you may see the same image referred to as
centos (implying the
Do not use the
How you tag the images dictates the updating policy. The more specific you are, the less frequently the image will be updated. Use the following to determine your chosen OKD images policy:
The vX.Y tag points to X.Y.Z-<number>. For example, if the
image is updated to v3.4, it points to the newest 3.4.Z-<number> tag, such
Similar to the vX.Y example above, the X.Y.Z tag points to the latest X.Y.Z-<number>. For example, 3.4.1 would point to 3.4.1-8
The tag is unique and does not change. When using this tag, the image does not update if an image is updated. For example, the 3.4.1-8 will always point to 3.4.1-8, even if an image is updated.
A container registry is a service for storing and retrieving Docker-formatted
container images. A registry contains a collection of one or more image
repositories. Each image repository contains one or more tagged images. Docker
provides its own registry, the Docker Hub, and you can also use private or third-party registries. Red Hat provides a
registry.access.redhat.com for subscribers. OKD can
also supply its own internal registry for managing custom container images.
The relationship between containers, images, and registries is depicted in the following diagram: