Managing Docker containers with Kubernetes
Services and Replication
Kubernetes supports two other very interesting features that I have not mentioned so far. Using a replication controller, you can scale pods horizontally. On the basis of a pod label, you can tell Kubernetes to provide the pod x times. Kubernetes then generates the desired number of instances of the container and makes them available on the existing minions. Kubernetes also handles the task of keeping the number of instances up to date. For example, if you stipulated that you want to have four instances of your Apache pods, Kubernetes would automatically start or stop Apache Docker instances until the number of instances corresponds to the definition.
Even if the individual containers get IP addresses from a network block defined previously in Docker, access to the individual instances of a pod are more typically via services. To offer this access, Kubernetes drops a kind of abstraction layer over specific pods of the same type and assigns a single IP address to this service. Access to the individual instances of a pod is then via that service IP. To allow this to happen, the request to the service IP is forwarded to the individual minions, and the kubelet proxy service on the minions is responsible for forwarding the request to the correct container.
You can imagine such a service as a kind of load balancer for a specific set of pods (Figure 1). For this system to work, every minion host must have an additional network segment from which the pod is then assigned an IP address. The kubelet proxy services forward the request to exactly this IP address. However, the only cloud provider that offers such a network configuration out of the box is the Google cloud platform. For all other providers, even if you use the Atomic image from this article in a local virtualization environment, a manual Docker service configuration is required. See the Docker documentation [9].
The flannel
tool [10], which is included in the most recent releases of the Atomic image, makes it very easy to set up overlay networks, which Docker can then draw on, thus saving you from extensive manual configuration.
Conclusions
Even though Kubernetes is currently profoundly beta and the tool's emphasis on the Google cloud engine is obvious, the gains in flexibility compared with plain vanilla Docker installations are already huge. Kubernetes defines an additional abstraction layer for the existing hardware resources and makes them available as a large pool of hardware.
Which system ultimately runs the container is unimportant. Kubernetes independently pools the necessary resources and starts the container wherever resources are available. Through the use of replication controllers, the framework also helps to scale existing containers horizontally.
Kubernetes services help to facilitate access to a service through a single IP address, thus eliminating the cumbersome process of discovering container IP addresses. This feature is particularly valuable when you consider the fact that containers can be short lived; they are typically restarted just a short time later on a different host; thus, their IP address might change. Services abstract these changes, removing the need for configurations such as upstream load balancers.
Infos
- Google Kubernetes: https://github.com/kubernetes/kubernetes
- Project Atomic: http://www.projectatomic.io/
- Red Hat Enterprise Linux 7 Atomic host: http://www.redhat.com/en/about/blog/small-footprint-big-impact-red-hat-enterprise-linux-7-atomic-host-beta-now-available
- Fedora Atomic host: https://getfedora.org/en/cloud/download/
- CentOS 7 Atomic host: http://buildlogs.centos.org/rolling/7/
- Etcd API documentation: https://github.com/coreos/etcd/blob/master/Documentation/api.md/
- Setup instructions for an Atomic VM https://access.redhat.com/articles/rhel-atomic-documentation/
- Cloud-init documentation: https://cloudinit.readthedocs.org/en/latest/
- Docker network documentation: http://docs.docker.com/engine/userguide/networking/
- Flannel overlay network: https://github.com/coreos/flannel/
« Previous 1 2
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs