diff options
| author | Brian Grant <bgrant0607@users.noreply.github.com> | 2017-02-20 11:33:24 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-02-20 11:33:24 -0800 |
| commit | fdf0911bb904a9f58b15b54ce61b8a245acdc805 (patch) | |
| tree | 781957a8a5b97f1e5b0c06226cc9a962efd3e707 | |
| parent | 0b20fbe192d628f6d7f6a6157f0a32d9aa505e6a (diff) | |
Update architecture.md
| -rw-r--r-- | contributors/design-proposals/architecture.md | 80 |
1 files changed, 1 insertions, 79 deletions
diff --git a/contributors/design-proposals/architecture.md b/contributors/design-proposals/architecture.md index 91043892..5cadd046 100644 --- a/contributors/design-proposals/architecture.md +++ b/contributors/design-proposals/architecture.md @@ -1,84 +1,6 @@ # Kubernetes architecture -A running Kubernetes cluster contains node agents (`kubelet`) and master -components (APIs, scheduler, etc), on top of a distributed storage solution. -This diagram shows our desired eventual state, though we're still working on a -few things, like making `kubelet` itself (all our components, really) run within -containers, and making the scheduler 100% pluggable. - - - -## The Kubernetes Node - -When looking at the architecture of the system, we'll break it down to services -that run on the worker node and services that compose the cluster-level control -plane. - -The Kubernetes node has the services necessary to run application containers and -be managed from the master systems. - -Each node runs a container runtime (like Docker, rkt or Hyper). The container -runtime is responsible for downloading images and running containers. - -### `kubelet` - -The `kubelet` manages [pods](../user-guide/pods.md) and their containers, their -images, their volumes, etc. - -### `kube-proxy` - -Each node also runs a simple network proxy and load balancer (see the -[services FAQ](https://github.com/kubernetes/kubernetes/wiki/Services-FAQ) for -more details). This reflects `services` (see -[the services doc](../user-guide/services.md) for more details) as defined in -the Kubernetes API on each node and can do simple TCP and UDP stream forwarding -(round robin) across a set of backends. - -Service endpoints are currently found via [DNS](../admin/dns.md) or through -environment variables (both -[Docker-links-compatible](https://docs.docker.com/userguide/dockerlinks/) and -Kubernetes `{FOO}_SERVICE_HOST` and `{FOO}_SERVICE_PORT` variables are -supported). These variables resolve to ports managed by the service proxy. - -## The Kubernetes Control Plane - -The Kubernetes control plane is split into a set of components. Currently they -all run on a single _master_ node, but that is expected to change soon in order -to support high-availability clusters. These components work together to provide -a unified view of the cluster. - -### `etcd` - -All persistent master state is stored in an instance of `etcd`. This provides a -great way to store configuration data reliably. With `watch` support, -coordinating components can be notified very quickly of changes. - -### Kubernetes API Server - -The apiserver serves up the [Kubernetes API](../api.md). It is intended to be a -CRUD-y server, with most/all business logic implemented in separate components -or in plug-ins. It mainly processes REST operations, validates them, and updates -the corresponding objects in `etcd` (and eventually other stores). - -### Scheduler - -The scheduler binds unscheduled pods to nodes via the `/binding` API. The -scheduler is pluggable, and we expect to support multiple cluster schedulers and -even user-provided schedulers in the future. - -### Kubernetes Controller Manager Server - -All other cluster-level functions are currently performed by the Controller -Manager. For instance, `Endpoints` objects are created and updated by the -endpoints controller, and nodes are discovered, managed, and monitored by the -node controller. These could eventually be split into separate components to -make them independently pluggable. - -The [`replicationcontroller`](../user-guide/replication-controller.md) is a -mechanism that is layered on top of the simple [`pod`](../user-guide/pods.md) -API. We eventually plan to port it to a generic plug-in mechanism, once one is -implemented. - +Please see the [Kubernetes design overview](README.md). <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> []() |
