mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-07 00:48:01 +01:00
50 lines
2.5 KiB
Plaintext
50 lines
2.5 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * architecture/architecture.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.
|
|
|
|
The two primary resources are:
|
|
|
|
`Machines`:: A fundamental unit that describes 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
|
|
Cluster 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.
|
|
|
|
|
|
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 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.
|