mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-11-04 04:08:16 +00:00
97 lines
4.6 KiB
Markdown
97 lines
4.6 KiB
Markdown
<!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
|
|
|
|
<!-- BEGIN STRIP_FOR_RELEASE -->
|
|
|
|
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
|
|
width="25" height="25">
|
|
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
|
|
width="25" height="25">
|
|
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
|
|
width="25" height="25">
|
|
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
|
|
width="25" height="25">
|
|
<img src="http://kubernetes.io/kubernetes/img/warning.png" alt="WARNING"
|
|
width="25" height="25">
|
|
|
|
<h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2>
|
|
|
|
If you are using a released version of Kubernetes, you should
|
|
refer to the docs that go with that version.
|
|
|
|
<!-- TAG RELEASE_LINK, added by the munger automatically -->
|
|
<strong>
|
|
The latest release of this document can be found
|
|
[here](http://releases.k8s.io/release-1.4/docs/design/README.md).
|
|
|
|
Documentation for other releases can be found at
|
|
[releases.k8s.io](http://releases.k8s.io).
|
|
</strong>
|
|
--
|
|
|
|
<!-- END STRIP_FOR_RELEASE -->
|
|
|
|
<!-- END MUNGE: UNVERSIONED_WARNING -->
|
|
|
|
# Kubernetes Design Overview
|
|
|
|
Kubernetes is a system for managing containerized applications across multiple
|
|
hosts, providing basic mechanisms for deployment, maintenance, and scaling of
|
|
applications.
|
|
|
|
Kubernetes establishes robust declarative primitives for maintaining the desired
|
|
state requested by the user. We see these primitives as the main value added by
|
|
Kubernetes. Self-healing mechanisms, such as auto-restarting, re-scheduling, and
|
|
replicating containers require active controllers, not just imperative
|
|
orchestration.
|
|
|
|
Kubernetes is primarily targeted at applications composed of multiple
|
|
containers, such as elastic, distributed micro-services. It is also designed to
|
|
facilitate migration of non-containerized application stacks to Kubernetes. It
|
|
therefore includes abstractions for grouping containers in both loosely coupled
|
|
and tightly coupled formations, and provides ways for containers to find and
|
|
communicate with each other in relatively familiar ways.
|
|
|
|
Kubernetes enables users to ask a cluster to run a set of containers. The system
|
|
automatically chooses hosts to run those containers on. While Kubernetes's
|
|
scheduler is currently very simple, we expect it to grow in sophistication over
|
|
time. Scheduling is a policy-rich, topology-aware, workload-specific function
|
|
that significantly impacts availability, performance, and capacity. The
|
|
scheduler needs to take into account individual and collective resource
|
|
requirements, quality of service requirements, hardware/software/policy
|
|
constraints, affinity and anti-affinity specifications, data locality,
|
|
inter-workload interference, deadlines, and so on. Workload-specific
|
|
requirements will be exposed through the API as necessary.
|
|
|
|
Kubernetes is intended to run on a number of cloud providers, as well as on
|
|
physical hosts.
|
|
|
|
A single Kubernetes cluster is not intended to span multiple availability zones.
|
|
Instead, we recommend building a higher-level layer to replicate complete
|
|
deployments of highly available applications across multiple zones (see
|
|
[the multi-cluster doc](../admin/multi-cluster.md) and [cluster federation proposal](../proposals/federation.md)
|
|
for more details).
|
|
|
|
Finally, Kubernetes aspires to be an extensible, pluggable, building-block OSS
|
|
platform and toolkit. Therefore, architecturally, we want Kubernetes to be built
|
|
as a collection of pluggable components and layers, with the ability to use
|
|
alternative schedulers, controllers, storage systems, and distribution
|
|
mechanisms, and we're evolving its current code in that direction. Furthermore,
|
|
we want others to be able to extend Kubernetes functionality, such as with
|
|
higher-level PaaS functionality or multi-cluster layers, without modification of
|
|
core Kubernetes source. Therefore, its API isn't just (or even necessarily
|
|
mainly) targeted at end users, but at tool and extension developers. Its APIs
|
|
are intended to serve as the foundation for an open ecosystem of tools,
|
|
automation systems, and higher-level API layers. Consequently, there are no
|
|
"internal" inter-component APIs. All APIs are visible and available, including
|
|
the APIs used by the scheduler, the node controller, the replication-controller
|
|
manager, Kubelet's API, etc. There's no glass to break -- in order to handle
|
|
more complex use cases, one can just access the lower-level APIs in a fully
|
|
transparent, composable manner.
|
|
|
|
For more about the Kubernetes architecture, see [architecture](architecture.md).
|
|
|
|
|
|
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
|
|
[]()
|
|
<!-- END MUNGE: GENERATED_ANALYTICS -->
|