Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

Chapter 1. Managing device fleets

The Red Hat Edge Manager simplifies the management of a large number of devices and workloads through device fleets. A fleet is a resource that defines a group of devices governed by a common device template and management policies.

When you make a change to the device template, all devices in the fleet receive the changes when the Red Hat Edge Manager agent detects the new target specification.

Device monitoring in a fleet is also simplified because you can check the status summary of the whole fleet.

Fleet-level management offers the following advantages:

  • Scales your operations because you perform operations only once for each fleet instead of once for each device.
  • Minimizes the risk of configuration mistakes and configuration drift.
  • Automatically applies the target configuration when you add devices to the fleet or replace devices in the fleet.

The fleet specification consists of the following features:

Label selector
Determines which devices are part of the fleet.
Device template
Defines the configuration that the Red Hat Edge Manager enforces on devices in the fleet.
Policies
Govern how devices are managed, for example, how changes to the device template are rolled out to the devices.

A fleet resource does not run software itself; it carries a device template whose specification—including choices you make from the Software Catalog—is enforced on each device that matches the fleet label selector. You can deploy or update catalog software on an individual device, or apply catalog items to a fleet so that the device template is updated and matching devices receive the software. Updates are available and can be applied from the Catalog tab when you open a device or a fleet in the Flight Control web console. Catalog updates use the same published upgrade paths for each catalog item, whether you target a single device or all devices governed by a fleet; see Validated upgrade paths and compatibility.

You can have both individually managed and fleet-managed devices at the same time. When a device is selected into a fleet, the Red Hat Edge Manager creates the device specification for the new device based on the device template. If you update the device template for a fleet or a new device joins the fleet, the Red Hat Edge Manager enforces the new specification in the fleet.

If a device is not selected into any fleets, the device is considered user-managed or unmanaged. For user-managed devices, you must update the device specification either manually or through an external automation.

Important: A device cannot be member of more than one fleet at the same time.

For more information, see Labels and label selectors.

1.1. Device selection into a fleet
Copiar o link

By default, devices are not assigned to a fleet. Instead, each fleet uses a selector that defines which labels a device must have to be added to the fleet.

To understand how to use labels in a fleet, see the following example:

The following list shows point-of-sales terminal devices and their labels:

Expand

Device

Labels

A

type: pos-terminal, region: east, stage: production

B

type: pos-terminal, region: east, stage: development

C

type: pos-terminal, region: west, stage: production

D

type: pos-terminal, region: west, stage: development

If all point-of-sales terminals uses the same configuration and are managed by the same operations team, you can define a single fleet called pos-terminals with the type=pos-terminal label selector. Then, the fleet contains devices A, B, C, and D.

However, you might want to create separate fleets for the different organizations for development or production. You can define a fleet for development with the type=pos-terminal, stage=development label selector, which selects devices C and D. Then, you can define another fleet for production with the type=pos-terminal, stage=production label selector. By using the correct label selectors, you can manage both fleets independently.

Important: You must define selectors in a way that two fleets do not select the same device. For example, if one fleet selects region=east, and another fleet selects stage=production, both fleets try to select device A. If two fleets try to select the same device, the Red Hat Edge Manager keeps the device in the currently assigned fleet, if any, and sets the OverlappingSelectors condition on the affected fleets to true.

1.2. Device templates
Copiar o link

A device template of a fleet contains a device specification that is applied to all devices in the fleet when the template is updated.

For example, you can specify in the device template of a fleet that all devices in the fleet must run the quay.io/flightctl/rhel:9.5 operating system image.

The Red Hat Edge Manager service then rolls out the target specification to all devices in the fleet and the Red Hat Edge Manager agents update each devices accordingly.

You can change other specification items in the device template and the Red Hat Edge Manager apply the changes in the same way.

However, sometimes not all of the devices in the fleet need to have the exact same specification. The Red Hat Edge Manager allows templates to contain placeholders that are populated based on the device name or label values.

The syntax of the placeholders matches that of Go templates. However, you can only use simple text and actions.

The use of conditionals or loops in the placeholders is not supported.

You can reference anything from the metadata of a device, such as {{ .metadata.labels.key }} or {{ .metadata.name }}.

You can also use the following functions in your placeholders:

  • The upper function changes the value to uppercase. For example, the function is {{ upper .metadata.name }}.
  • The lower function changes the value to lowercase. For example, the function is {{ lower .metadata.labels.key }}.
  • The replace function replaces all occurrences of a substring with another string. For example, the function is {{ replace "old" "new" .metadata.labels.key }}.
  • The getOrDefault function returns a default value if accessing a missing label. For example, he function is {{ getOrDefault .metadata.labels "key" "default" }}.

You can combine the functions in pipelines, for example, a combined function is {{ getOrDefault .metadata.labels "key" "default" | upper | replace " " "-" }}.

Note: Ensure using proper Go template syntax. For example, {{ .metadata.labels.target-revision }} is not valid because of the hyphen. Instead, you must refer to the field as {{ index .metadata.labels "target-revision" }}.

You can use the placeholders in device templates in the following ways:

  • You can label devices by deployment stage, for example, stage labels are stage: testing and stage: production. Then, you can use the label with the stage key as placeholder when referencing the operating system image to use, for example, use quay.io/myorg/myimage:latest-{{ .metadata.labels.stage }} or when referencing a configuration folder in a Git repository.
  • You can label devices by deployment site, for example, deployment sites are site: factory-berlin and site: factory-madrid.
  • Then, you can use the label with the site key as parameter when referencing the secret with network access credentials in Kubernetes.

The following fields in device templates support placeholders:

Expand

Field

Placeholders supported in

Operating System Image

repository name, image name, image tag

Git Config Provider

target revision, path

HTTP Config Provider

URL suffix, path

Inline Config Provider

content, path

To configure a fleet device template so that MicroShift clusters on devices in the fleet auto-register with Red Hat Advanced Cluster Management, see Configuring fleets to auto-register MicroShift clusters.

1.3. Selecting devices into a fleet by using the CLI
Copiar o link

Define label selector to add devices into a fleet.

Complete the following tasks:

  1. Run the following command to verify that the label selector returns the devices that you want to add to the fleet: 

    flightctl get devices -l type=pos-terminal -l stage=development

  2. If running the command returns the expected list of devices, you can define a fleet that selects the devices by using the following YAML file: 

    apiVersion: flightctl.io/v1alpha1
kind: Fleet
metadata:
  name: my_fleet
spec:
  selector:
    matchLabels:
      type: pos-terminal
      stage: development
[...]

  3. Apply the change by running the following command: 

    flightctl apply -f my_fleet.yaml

  4. Check for any overlaps with the selector of other fleets by running the following command: 

    flightctl get fleets/my_fleet -o json | jq -r '.status.conditions[] | select(.type=="OverlappingSelectors").status'

    See the following example output: 

    False

1.4. Configuring fleets to auto-register MicroShift clusters
Copiar o link

If you have fleets of devices that are running an operating system image that includes MicroShift, you can configure your fleets to auto-register MicroShift clusters with Red Hat Advanced Cluster Management.

1.4.1. Configuring your device template
Copiar o link

To enable auto-registration in a fleet, add configuration to its device template.

If you have not already created the HTTP Repository named acm-registration for the Red Hat Advanced Cluster Management agent registration API (including validationSuffix and httpConfig), create it by following the repository steps in Configuring your device in Managing devices.

Complete the following steps:

  1. Add the acm-crd resource configuration, which includes the filePath for your crd.yaml file, your repository, and suffix to your Fleet resource. See the following example: 

    apiVersion: flightctl.io/v1alpha1
kind: Fleet
metadata:
  name: fleet-acm
spec:
  selector:
    matchLabels:
      fleet: acm
  template:
    spec:
      os:
        image: <your os image>
      config:
        - name: acm-crd
          httpRef:
            filePath: /var/local/acm-import/crd.yaml
            repository: acm-registration
            suffix: /agent-registration/crds/v1

  2. Add the acm-import resource configuration with the filePath, repository, and suffix, as you see in the following example: 

          config:
        - name: acm-import
          httpRef:
            filePath: /var/local/acm-import/import.yaml
            repository: acm-registration
            suffix: /agent-registration/manifests/{{.metadata.name}}

  3. MicroShift must authenticate to the container registries that host the Red Hat Advanced Cluster Management images. If the device already has a suitable pull secret for those registries (for example, at /etc/crio/openshift-pull-secret), you do not need to add another one here. Otherwise, add the pull-secret resource, as you see in the following addition to the template: 

          config:
        - name: pull-secret
          inline:
            - path: "/etc/crio/openshift-pull-secret"
              content: "{\"auths\":{...}}"

  4. Add the apply-acm-manifests resource. The following hook waits until the kubeadmin kubeconfig file exists and MicroShift pods are ready, then runs kubectl apply on your crd.yaml and import.yaml files when those files are created. Include those wait steps when MicroShift might not be running when the hook runs, for example if you apply an operating system image update and this registration configuration together in a single device update. See the following example: 

          config:
        - name: apply-acm-manifests
          inline:
            - path: "/etc/flightctl/hooks.d/afterupdating/50-acm-registration.yaml"
              content: |
                - run: /usr/bin/bash -c "until [ -f $KUBECONFIG ]; do sleep 1; done"
                  timeout: 5m
                  envVars:
                    KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
                - run: kubectl wait --for=condition=Ready pods --all --all-namespaces --timeout=300s
                  timeout: 5m
                  envVars:
                    KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
                - if:
                  - path: /var/local/acm-import/crd.yaml
                    op: [created]
                  run: kubectl apply -f /var/local/acm-import/crd.yaml
                  envVars:
                    KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig
                - if:
                  - path: /var/local/acm-import/import.yaml
                    op: [created]
                  run: kubectl apply -f /var/local/acm-import/import.yaml
                  envVars:
                    KUBECONFIG: /var/lib/microshift/resources/kubeadmin/kubeconfig

    Auto-registration uses the Red Hat Advanced Cluster Management agent registration API: devices fetch the Kubernetes manifests for the klusterlet agent and apply them to MicroShift. The resources under spec.template.spec.config in your fleet template do the following:

    • acm-crd uses the HTTP configuration provider to query the agent registration server for manifests that contain the custom resource definition for the Red Hat Advanced Cluster Management klusterlet agent. The Red Hat Edge Manager agent writes those manifests to /var/local/acm-import/crd.yaml on each device.
    • acm-import queries the server for import manifests for a cluster whose name matches the device. The {{.metadata.name}} template variable supplies the device name. The agent writes the returned manifests to /var/local/acm-import/import.yaml.
    • pull-secret adds registry credentials on the device so that MicroShift can pull the Red Hat Advanced Cluster Management agent images. Skip this item if you already provide a suitable pull secret by another method, for example by embedding it in the operating system image or by using another configuration provider.
    • apply-acm-manifests adds an afterupdating lifecycle hook rule file under /etc/flightctl/hooks.d/afterupdating/. The hook runs after the configuration is applied and the crd.yaml and import.yaml files exist; it applies those manifests to MicroShift by using kubectl. For more information, see Device lifecycle hooks.
  5. In the console, label the device fleet:acm and click Approve, which automatically selects the fleet-acm fleet. For more information about labels on devices, see Labels and label selectors.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Legal Notice

Theme

© 2026 Red HatVoltar ao topo