mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-06 06:46:26 +01:00
64 lines
3.2 KiB
Plaintext
64 lines
3.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * machine_management/creating_machinesets/creating-machineset-aws.adoc
|
|
// * machine_management/creating_machinesets/creating-machineset-azure.adoc
|
|
// * machine_management/creating_machinesets/creating-machineset-gcp.adoc
|
|
// * machine_management/creating_machinesets/creating-machineset-osp.adoc
|
|
// * machine_management/creating_machinesets/creating-machineset-vsphere.adoc
|
|
|
|
[id="machine-api-overview_{context}"]
|
|
= Machine API overview
|
|
|
|
The Machine API is a combination of primary resources that are based on the
|
|
upstream Cluster API project and custom {product-title} resources.
|
|
|
|
For {product-title} {product-version} clusters, the Machine API performs all node
|
|
host provisioning management actions after the cluster installation finishes.
|
|
Because of this system, {product-title} {product-version} offers an elastic,
|
|
dynamic provisioning method on top of public or private cloud infrastructure.
|
|
|
|
The two primary resources are:
|
|
|
|
Machines:: A fundamental unit that describes the host for a Node. A machine has a
|
|
providerSpec, which describes the types of compute nodes that are offered for different
|
|
cloud platforms. For example, a machine type for a worker node on Amazon Web
|
|
Services (AWS) might define a specific machine type and required metadata.
|
|
MachineSets:: Groups of machines. MachineSets are to machines as
|
|
ReplicaSets are to pods. If you need more machines or must scale them down,
|
|
you change the *replicas* field on the MachineSet to meet your compute need.
|
|
|
|
The following custom resources add more capabilities to your cluster:
|
|
|
|
MachineAutoscaler:: This resource automatically scales machines in
|
|
a cloud. You can set the minimum and maximum scaling boundaries for nodes in a
|
|
specified MachineSet, and the MachineAutoscaler maintains that range of nodes.
|
|
The MachineAutoscaler object takes effect after a ClusterAutoscaler object
|
|
exists. Both ClusterAutoscaler and MachineAutoscaler resources are made
|
|
available by the ClusterAutoscalerOperator.
|
|
|
|
ClusterAutoscaler:: This resource is based on the upstream ClusterAutoscaler
|
|
project. In the {product-title} implementation, it is integrated with the
|
|
Machine API by extending the MachineSet API. You can set cluster-wide
|
|
scaling limits for resources such as cores, nodes, memory, GPU,
|
|
and so on. You can set the priority so that the cluster prioritizes pods so that
|
|
new nodes are not brought online for less important pods. You can also set the
|
|
ScalingPolicy so you can scale up nodes but not scale them down.
|
|
|
|
MachineHealthCheck:: This resource detects when a machine is unhealthy,
|
|
deletes it, and, on supported platforms, makes a new machine.
|
|
+
|
|
[NOTE]
|
|
====
|
|
In version {product-version}, MachineHealthChecks is a Technology Preview
|
|
feature
|
|
====
|
|
|
|
In {product-title} version 3.11, you could not roll out a multi-zone
|
|
architecture easily because the cluster did not manage machine provisioning.
|
|
Beginning with {product-title} version 4.1, this process is easier. Each MachineSet is scoped to a
|
|
single zone, so the installation program sends out MachineSets across
|
|
availability zones on your behalf. And then because your compute is dynamic, and
|
|
in the face of a zone failure, you always have a zone for when you must
|
|
rebalance your machines. The autoscaler provides best-effort balancing over the
|
|
life of a cluster.
|