136 lines
5.3 KiB
Markdown
136 lines
5.3 KiB
Markdown
---
|
|
reviewers:
|
|
- lavalamp
|
|
title: Kubernetes Components
|
|
content_type: concept
|
|
description: >
|
|
A Kubernetes cluster consists of the components that represent the control plane
|
|
and a set of machines called nodes.
|
|
weight: 20
|
|
card:
|
|
name: concepts
|
|
weight: 20
|
|
---
|
|
|
|
<!-- overview -->
|
|
When you deploy Kubernetes, you get a cluster.
|
|
{{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}}
|
|
|
|
This document outlines the various components you need to have
|
|
a complete and working Kubernetes cluster.
|
|
|
|
Here's the diagram of a Kubernetes cluster with all the components tied together.
|
|
|
|
|
|
|
|
|
|
|
|
<!-- body -->
|
|
## Control Plane Components
|
|
|
|
The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
|
|
|
|
Control plane components can be run on any machine in the cluster. However,
|
|
for simplicity, set up scripts typically start all control plane components on
|
|
the same machine, and do not run user containers on this machine. See
|
|
[Building High-Availability Clusters](/docs/admin/high-availability/) for an example multi-master-VM setup.
|
|
|
|
### kube-apiserver
|
|
|
|
{{< glossary_definition term_id="kube-apiserver" length="all" >}}
|
|
|
|
### etcd
|
|
|
|
{{< glossary_definition term_id="etcd" length="all" >}}
|
|
|
|
### kube-scheduler
|
|
|
|
{{< glossary_definition term_id="kube-scheduler" length="all" >}}
|
|
|
|
### kube-controller-manager
|
|
|
|
{{< glossary_definition term_id="kube-controller-manager" length="all" >}}
|
|
|
|
Some types of these controllers are:
|
|
|
|
* Node controller: Responsible for noticing and responding when nodes go down.
|
|
* Job controller: Watches for Job objects that represent one-off tasks, then creates
|
|
Pods to run those tasks to completion.
|
|
* Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods).
|
|
* Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
|
|
|
|
### cloud-controller-manager
|
|
|
|
{{< glossary_definition term_id="cloud-controller-manager" length="short" >}}
|
|
|
|
The cloud-controller-manager only runs controllers that are specific to your cloud provider.
|
|
If you are running Kubernetes on your own premises, or in a learning environment inside your
|
|
own PC, the cluster does not have a cloud controller manager.
|
|
|
|
As with the kube-controller-manager, the cloud-controller-manager combines several logically
|
|
independent control loops into a single binary that you run as a single process. You can
|
|
scale horizontally (run more than one copy) to improve performance or to help tolerate failures.
|
|
|
|
The following controllers can have cloud provider dependencies:
|
|
|
|
* Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
|
|
* Route controller: For setting up routes in the underlying cloud infrastructure
|
|
* Service controller: For creating, updating and deleting cloud provider load balancers
|
|
|
|
## Node Components
|
|
|
|
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
|
|
|
|
### kubelet
|
|
|
|
{{< glossary_definition term_id="kubelet" length="all" >}}
|
|
|
|
### kube-proxy
|
|
|
|
{{< glossary_definition term_id="kube-proxy" length="all" >}}
|
|
|
|
### Container runtime
|
|
|
|
{{< glossary_definition term_id="container-runtime" length="all" >}}
|
|
|
|
## Addons
|
|
|
|
Addons use Kubernetes resources ({{< glossary_tooltip term_id="daemonset" >}},
|
|
{{< glossary_tooltip term_id="deployment" >}}, etc)
|
|
to implement cluster features. Because these are providing cluster-level features, namespaced resources
|
|
for addons belong within the `kube-system` namespace.
|
|
|
|
Selected addons are described below; for an extended list of available addons, please
|
|
see [Addons](/docs/concepts/cluster-administration/addons/).
|
|
|
|
### DNS
|
|
|
|
While the other addons are not strictly required, all Kubernetes clusters should have [cluster DNS](/docs/concepts/services-networking/dns-pod-service/), as many examples rely on it.
|
|
|
|
Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services.
|
|
|
|
Containers started by Kubernetes automatically include this DNS server in their DNS searches.
|
|
|
|
### Web UI (Dashboard)
|
|
|
|
[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.
|
|
|
|
### Container Resource Monitoring
|
|
|
|
[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics
|
|
about containers in a central database, and provides a UI for browsing that data.
|
|
|
|
### Cluster-level Logging
|
|
|
|
A [cluster-level logging](/docs/concepts/cluster-administration/logging/) mechanism is responsible for
|
|
saving container logs to a central log store with search/browsing interface.
|
|
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
* Learn about [Nodes](/docs/concepts/architecture/nodes/)
|
|
* Learn about [Controllers](/docs/concepts/architecture/controller/)
|
|
* Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/)
|
|
* Read etcd's official [documentation](https://etcd.io/docs/)
|
|
|