mirror of
				https://github.com/k3s-io/kubernetes.git
				synced 2025-10-30 21:30:16 +00:00 
			
		
		
		
	
		
			
				
	
	
		
			206 lines
		
	
	
		
			7.4 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
			
		
		
	
	
			206 lines
		
	
	
		
			7.4 KiB
		
	
	
	
		
			Markdown
		
	
	
	
	
	
| <!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
 | |
| 
 | |
| <!-- BEGIN STRIP_FOR_RELEASE -->
 | |
| 
 | |
| <img src="http://kubernetes.io/img/warning.png" alt="WARNING"
 | |
|      width="25" height="25">
 | |
| <img src="http://kubernetes.io/img/warning.png" alt="WARNING"
 | |
|      width="25" height="25">
 | |
| <img src="http://kubernetes.io/img/warning.png" alt="WARNING"
 | |
|      width="25" height="25">
 | |
| <img src="http://kubernetes.io/img/warning.png" alt="WARNING"
 | |
|      width="25" height="25">
 | |
| <img src="http://kubernetes.io/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.1/docs/admin/cluster-components.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 Cluster Admin Guide: Cluster Components
 | |
| 
 | |
| **Table of Contents**
 | |
| 
 | |
| <!-- BEGIN MUNGE: GENERATED_TOC -->
 | |
| 
 | |
| - [Kubernetes Cluster Admin Guide: Cluster Components](#kubernetes-cluster-admin-guide-cluster-components)
 | |
|   - [Master Components](#master-components)
 | |
|     - [kube-apiserver](#kube-apiserver)
 | |
|     - [etcd](#etcd)
 | |
|     - [kube-controller-manager](#kube-controller-manager)
 | |
|     - [kube-scheduler](#kube-scheduler)
 | |
|     - [addons](#addons)
 | |
|       - [DNS](#dns)
 | |
|       - [User interface](#user-interface)
 | |
|       - [Container Resource Monitoring](#container-resource-monitoring)
 | |
|       - [Cluster-level Logging](#cluster-level-logging)
 | |
|   - [Node components](#node-components)
 | |
|     - [kubelet](#kubelet)
 | |
|     - [kube-proxy](#kube-proxy)
 | |
|     - [docker](#docker)
 | |
|     - [rkt](#rkt)
 | |
|     - [supervisord](#supervisord)
 | |
|     - [fluentd](#fluentd)
 | |
| 
 | |
| <!-- END MUNGE: GENERATED_TOC -->
 | |
| 
 | |
| This document outlines the various binary components that need to run to
 | |
| deliver a functioning Kubernetes cluster.
 | |
| 
 | |
| ## Master Components
 | |
| 
 | |
| Master components are those that provide the cluster's control plane. For
 | |
| example, master components are responsible for making global decisions about the
 | |
| cluster (e.g., scheduling), and detecting and responding to cluster events
 | |
| (e.g., starting up a new pod when a replication controller's 'replicas' field is
 | |
| unsatisfied).
 | |
| 
 | |
| Master components could in theory be run on any node in the cluster. However,
 | |
| for simplicity, current set up scripts typically start all master components on
 | |
| the same VM, and does not run user containers on this VM. See
 | |
| [high-availability.md](high-availability.md) for an example multi-master-VM setup.
 | |
| 
 | |
| Even in the future, when Kubernetes is fully self-hosting, it will probably be
 | |
| wise to only allow master components to schedule on a subset of nodes, to limit
 | |
| co-running with user-run pods, reducing the possible scope of a
 | |
| node-compromising security exploit.
 | |
| 
 | |
| ### kube-apiserver
 | |
| 
 | |
| [kube-apiserver](kube-apiserver.md) exposes the Kubernetes API; it is the front-end for the
 | |
| Kubernetes control plane. It is designed to scale horizontally (i.e., one scales
 | |
| it by running more of them-- [high-availability.md](high-availability.md)).
 | |
| 
 | |
| ### etcd
 | |
| 
 | |
| [etcd](etcd.md) is used as Kubernetes' backing store. All cluster data is stored here.
 | |
| Proper administration of a Kubernetes cluster includes a backup plan for etcd's
 | |
| data.
 | |
| 
 | |
| ### kube-controller-manager
 | |
| 
 | |
| [kube-controller-manager](kube-controller-manager.md) is a binary that runs controllers, which are the
 | |
| background threads that handle routine tasks in the cluster. Logically, each
 | |
| controller is a separate process, but to reduce the number of moving pieces in
 | |
| the system, they are all compiled into a single binary and run in a single
 | |
| process.
 | |
| 
 | |
| These controllers include:
 | |
| 
 | |
| * Node Controller
 | |
|  * Responsible for noticing & responding when nodes go down.
 | |
| * Replication Controller
 | |
|  * Responsible for maintaining the correct number of pods for every replication
 | |
|    controller object in the system.
 | |
| * Endpoints Controller
 | |
|  * Populates the Endpoints object (i.e., join Services & Pods).
 | |
| * Service Account & Token Controllers
 | |
|  * Create default accounts and API access tokens for new namespaces.
 | |
| * ... and others.
 | |
| 
 | |
| ### kube-scheduler
 | |
| 
 | |
| [kube-scheduler](kube-scheduler.md) watches newly created pods that have no node assigned, and
 | |
| selects a node for them to run on.
 | |
| 
 | |
| ### addons
 | |
| 
 | |
| Addons are pods and services that implement cluster features. They don't run on
 | |
| the master VM, but currently the default setup scripts that make the API calls
 | |
| to create these pods and services does run on the master VM. See:
 | |
| [kube-master-addons](http://releases.k8s.io/HEAD/cluster/saltbase/salt/kube-master-addons/kube-master-addons.sh)
 | |
| 
 | |
| Addon objects are created in the "kube-system" namespace.
 | |
| 
 | |
| #### DNS
 | |
| 
 | |
| While the other addons are not strictly required, all Kubernetes
 | |
| clusters should have [cluster DNS](dns.md), 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.
 | |
| 
 | |
| #### User interface
 | |
| 
 | |
| The kube-ui provides a read-only overview of the cluster state.  Access
 | |
| [the UI using kubectl proxy](../user-guide/connecting-to-applications-proxy.md#connecting-to-the-kube-ui-service-from-your-local-workstation)
 | |
| 
 | |
| #### Container Resource Monitoring
 | |
| 
 | |
| [Container Resource Monitoring](../user-guide/monitoring.md) records generic time-series metrics
 | |
| about containers in a central database, and provides a UI for browsing that data.
 | |
| 
 | |
| #### Cluster-level Logging
 | |
| 
 | |
| [Container Logging](../user-guide/monitoring.md) saves container logs
 | |
| to a central log store with search/browsing interface.  There are two
 | |
| implementations:
 | |
| 
 | |
| * [Cluster-level logging to Google Cloud Logging](
 | |
| docs/user-guide/logging.md#cluster-level-logging-to-google-cloud-logging)
 | |
| 
 | |
| * [Cluster-level Logging with Elasticsearch and Kibana](
 | |
| docs/user-guide/logging.md#cluster-level-logging-with-elasticsearch-and-kibana)
 | |
| 
 | |
| ## Node components
 | |
| 
 | |
| Node components run on every node, maintaining running pods and providing them
 | |
| the Kubernetes runtime environment.
 | |
| 
 | |
| ### kubelet
 | |
| 
 | |
| [kubelet](kubelet.md) is the primary node agent. It:
 | |
| * Watches for pods that have been assigned to its node (either by apiserver
 | |
|   or via local configuration file) and:
 | |
|  * Mounts the pod's required volumes
 | |
|  * Downloads the pod's secrets
 | |
|  * Run the pod's containers via docker (or, experimentally, rkt).
 | |
|  * Periodically executes any requested container liveness probes.
 | |
|  * Reports the status of the pod back to the rest of the system, by creating a
 | |
|    "mirror pod" if necessary.
 | |
| * Reports the status of the node back to the rest of the system.
 | |
| 
 | |
| ### kube-proxy
 | |
| 
 | |
| [kube-proxy](kube-proxy.md) enables the Kubernetes service abstraction by maintaining
 | |
| network rules on the host and performing connection forwarding.
 | |
| 
 | |
| ### docker
 | |
| 
 | |
| `docker` is of course used for actually running containers.
 | |
| 
 | |
| ### rkt
 | |
| 
 | |
| `rkt` is supported experimentally as an alternative to docker.
 | |
| 
 | |
| ### supervisord
 | |
| 
 | |
| `supervisord` is a lightweight process babysitting system for keeping kubelet and docker
 | |
| running.
 | |
| 
 | |
| ### fluentd
 | |
| 
 | |
| `fluentd` is a daemon which helps provide [cluster-level logging](#cluster-level-logging).
 | |
| 
 | |
| <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
 | |
| []()
 | |
| <!-- END MUNGE: GENERATED_ANALYTICS -->
 |