Concepts

HOMESETUPCONCEPTSTASKSTUTORIALSREFERENCECONTRIBUTE

Search

What is Kubernetes

This page is an overview of Kubernetes.

Why do I need Kubernetes and what can it do

How Kubernetes is a platform
What Kubernetes is not
Why containers
What Kubernetes and K8s mean
What's next

Kubernetes is a portable, extensible open-source platform for managing containerized

workloads and services, that facilitates both declarative con?guration and automation. It has a
large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a
half of experience that Google has with running production workloads at scale, combined with
best-of-breed ideas and practices from the community.

Why do I need Kubernetes and what can it do

Kubernetes has a number of features. It can be thought of as:

a container platform

a microservices platform
 a portable cloud platform and a lot more.

Kubernetes provides a container-centric management environment. It orchestrates

computing, networking, and storage infrastructure on behalf of user workloads. This provides
much of the simplicity of Platform as a Service (PaaS) with the Mexibility of Infrastructure as a
Service (IaaS), and enables portability across infrastructure providers.

How Kubernetes is a platform

Even though Kubernetes provides a lot of functionality, there are always new scenarios that
would bene?t from new features. Application-speci?c workMows can be streamlined to
accelerate developer velocity. Ad hoc orchestration that is acceptable initially often requires
robust automation at scale. This is why Kubernetes was also designed to serve as a platform
for building an ecosystem of components and tools to make it easier to deploy, scale, and
manage applications.

Labels empower users to organize their resources however they please. Annotations enable
users to decorate resources with custom information to facilitate their workMows and provide
an easy way for management tools to checkpoint state.

Additionally, the Kubernetes control plane is built upon the same APIs that are available to
developers and users. Users can write their own controllers, such as schedulers, with their
own APIs that can be targeted by a general-purpose command-line tool.

This design has enabled a number of other systems to build atop Kubernetes.

What Kubernetes is not

Kubernetes is not a traditional, all-inclusive PaaS (Platform as a Service) system. Since

Kubernetes operates at the container level rather than at the hardware level, it provides some
generally applicable features common to PaaS offerings, such as deployment, scaling, load
balancing, logging, and monitoring. However, Kubernetes is not monolithic, and these default
solutions are optional and pluggable. Kubernetes provides the building blocks for building
developer platforms, but preserves user choice and Mexibility where it is important.

Kubernetes:
 Does not limit the types of applications supported. Kubernetes aims to support an
extremely diverse variety of workloads, including stateless, stateful, and data-processing
workloads. If an application can run in a container, it should run great on Kubernetes.

Does not deploy source code and does not build your application. Continuous Integration,
Delivery, and Deployment (CI/CD) workMows are determined by organization cultures and
preferences as well as technical requirements.

Does not provide application-level services, such as middleware (e.g., message buses),
data-processing frameworks (for example, Spark), databases (e.g., mysql), caches, nor
cluster storage systems (e.g., Ceph) as built-in services. Such components can run on
Kubernetes, and/or can be accessed by applications running on Kubernetes through
portable mechanisms, such as the Open Service Broker.

Does not dictate logging, monitoring, or alerting solutions. It provides some integrations
as proof of concept, and mechanisms to collect and export metrics.

Does not provide nor mandate a con?guration language/system (e.g., jsonnet). It provides
a declarative API that may be targeted by arbitrary forms of declarative speci?cations.

Does not provide nor adopt any comprehensive machine con?guration, maintenance,
management, or self-healing systems.

Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for
orchestration. The technical de?nition of orchestration is execution of a de?ned workMow: ?rst
do A, then B, then C. In contrast, Kubernetes is comprised of a set of independent, composable
control processes that continuously drive the current state towards the provided desired state.
It shouldn’t matter how you get from A to C. Centralized control is also not required. This
results in a system that is easier to use and more powerful, robust, resilient, and extensible.

Why containers

Looking for reasons why you should be using containers?

The Old Way to deploy applications was to install the applications on a host using the
operating-system package manager. This had the disadvantage of entangling the applications’
executables, con?guration, libraries, and lifecycles with each other and with the host OS. One
could build immutable virtual-machine images in order to achieve predictable rollouts and
rollbacks, but VMs are heavyweight and non-portable.

The New Way is to deploy containers based on operating-system-level virtualization rather

than hardware virtualization. These containers are isolated from each other and from the host:
they have their own ?lesystems, they can’t see each others’ processes, and their
computational resource usage can be bounded. They are easier to build than VMs, and
because they are decoupled from the underlying infrastructure and from the host ?lesystem,
they are portable across clouds and OS distributions.

Because containers are small and fast, one application can be packed in each container
image. This one-to-one application-to-image relationship unlocks the full bene?ts of
containers. With containers, immutable container images can be created at build/release time
rather than deployment time, since each application doesn’t need to be composed with the
rest of the application stack, nor married to the production infrastructure environment.
Generating container images at build/release time enables a consistent environment to be
carried from development into production. Similarly, containers are vastly more transparent
than VMs, which facilitates monitoring and management. This is especially true when the
containers’ process lifecycles are managed by the infrastructure rather than hidden by a
process supervisor inside the container. Finally, with a single application per container,
managing the containers becomes tantamount to managing deployment of the application.

Summary of container bene?ts:

Agile application creation and deployment: Increased ease and e^ciency of container
image creation compared to VM image use.

Continuous development, integration, and deployment: Provides for reliable and frequent
container image build and deployment with quick and easy rollbacks (due to image
immutability).

Dev and Ops separation of concerns: Create application container images at

build/release time rather than deployment time, thereby decoupling applications from
infrastructure.

Observability Not only surfaces OS-level information and metrics, but also application
health and other signals.

Environmental consistency across development, testing, and production: Runs the

same on a laptop as it does in the cloud.

Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-prem, Google
Kubernetes Engine, and anywhere else.

Application-centric management: Raises the level of abstraction from running an OS on

virtual hardware to running an application on an OS using logical resources.

Loosely coupled, distributed, elastic, liberated micro-services: Applications are broken

into smaller, independent pieces and can be deployed and managed dynamically – not a
monolithic stack running on one big single-purpose machine.

Resource isolation: Predictable application performance.

Resource utilization: High e^ciency and density.

What Kubernetes and K8s mean

The name Kubernetes originates from Greek, meaning helmsman or pilot, and is the root of
governor and cybernetic. K8s is an abbreviation derived by replacing the 8 letters “ubernete”
with “8”.

What's next

Ready to Get Started?

For more details, see the Kubernetes Documentation.

Feedback

Was this page helpful?

Yes No

Create an Issue Edit This Page

Page last modi7ed on April 26, 2019 at 9:54 AM PST by keep consistent with others' heading
(#14002) (Page History)

Home

Blog
Partners

Community

Case Studies
 Contribute

© 2019 The Kubernetes Authors | Documentation Distributed under CC BY 4.0

Copyright © 2019 The Linux Foundation ®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list
of trademarks of The Linux Foundation, please see our Trademark Usage page
ICP license: ICP 17074266 -3