Use Control Plane instead of Master (#18438)
* Use Control Plane instead of Master * improve image. The SVG was not matching the PNG, so I basically had to re-create it from scratch. I kept the visual similarities as mush as possible * remove tautological phrase * fix glossary references as well * improve cluster glossary to move from Master to Control Plane * improve english formpull/18729/head
parent
8f8bb5c2bf
commit
99ca9c0397
|
@ -11,7 +11,7 @@ card:
|
|||
|
||||
{{% capture overview %}}
|
||||
When you deploy Kubernetes, you get a cluster.
|
||||
{{< glossary_definition term_id="cluster" length="all" prepend="A cluster is">}}
|
||||
{{< 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.
|
||||
|
@ -23,13 +23,12 @@ Here's the diagram of a Kubernetes cluster with all the components tied together
|
|||
{{% /capture %}}
|
||||
|
||||
{{% capture body %}}
|
||||
## Master Components
|
||||
## Control Plane Components
|
||||
|
||||
Master components provide the cluster's control plane. Master components make global decisions about the
|
||||
cluster (for example, scheduling), and they detect and respond to cluster events (for example, starting up a new {{< glossary_tooltip text="pod" term_id="pod">}} when a deployment's `replicas` field is unsatisfied).
|
||||
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).
|
||||
|
||||
Master components can be run on any machine in the cluster. However,
|
||||
for simplicity, set up scripts typically start all master components on
|
||||
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.
|
||||
|
||||
|
|
|
@ -4,14 +4,14 @@ id: cluster
|
|||
date: 2019-06-15
|
||||
full_link:
|
||||
short_description: >
|
||||
A set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node.
|
||||
A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
A set of machines, called nodes, that run containerized applications managed by Kubernetes. A cluster has at least one worker node and at least one master node.
|
||||
A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
|
||||
|
||||
<!--more-->
|
||||
The worker node(s) host the pods that are the components of the application. The master node(s) manages the worker nodes and the pods in the cluster. Multiple master nodes are used to provide a cluster with failover and high availability.
|
||||
The worker node(s) host the pods that are the components of the application. The Control Plane manages the worker nodes and the pods in the cluster. In production environments, the Control Plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
|
||||
|
|
|
@ -4,14 +4,14 @@ id: kube-controller-manager
|
|||
date: 2018-04-12
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
|
||||
short_description: >
|
||||
Component on the master that runs controllers.
|
||||
Control Plane component that runs controller processes.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Component on the master that runs {{< glossary_tooltip text="controllers" term_id="controller" >}}.
|
||||
Control Plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
|
|
@ -4,15 +4,15 @@ id: kube-scheduler
|
|||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
short_description: >
|
||||
Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.
|
||||
Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- architecture
|
||||
---
|
||||
Component on the master that watches newly created pods that have no node assigned, and selects a node for them to run on.
|
||||
Control Plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines.
|
||||
Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines.
|
||||
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 269 KiB After Width: | Height: | Size: 152 KiB |
File diff suppressed because it is too large
Load Diff
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 45 KiB |
Loading…
Reference in New Issue