Ask an OpenShift Admin (E95) | Agent Based Installer

Main topic: OpenShift Agent-Based Installer (focused demo + guidance)

The session introduces OpenShift’s agent-based installer (previously in progress; noted as GA-ready/available alongside OpenShift 4.10, with newer iterations discussed).

Core idea

Instead of performing a traditional install from a “bastion/admin” host to create ignition/manifests end-to-end, the agent-based approach aims to quickly bootstrap “cluster zero” by:

• Creating an agent ISO (from two config files)
• Handing that ISO to the target environment (common for disconnected or edge/remote sites)
• Booting VMs/bare-metal nodes to that ISO so the cluster comes up with minimal operator involvement afterward

---

Product features / behavior described

Primary use case: Disconnected installs

• The installer still requires that the needed OpenShift images are mirrored into an install registry (similar requirement to other disconnected workflows).
• However, it avoids needing interactive remote admin workflows (like hosting a bastion) just to kick off ignition-based installation.
• For an edge/remote environment:
  • Generate the ISO in a connected environment
  • Transfer it to the target site
  • The target site can complete bootstrap autonomously

Other scenario mentioned: Small site provisioning

• A central team can prepare the ISO.
• The local site can boot it to get a cluster running without being highly skilled in OpenShift deployment procedures.

Demo outcome goal

A “b boring demo” flow:

• Create two files
• Generate ISO
• Boot nodes
• Wait
• End up with a working OpenShift cluster

---

Demo walkthrough (technical steps + requirements)

1. Create an install configuration

   • Standard-ish OpenShift install-config style.
   • Includes:
     • Cluster networking
     • Service network
     • Machine network
     • Pull secret
     • SSH key
     • Node sizing/type configuration

2. Create an agent configuration

   • Includes at least:
     • Rendezvous IP (points to the bootstrap node; in the demo, the first VM)
     • Network interface selection & configuration
       • The agent-based installer applies per-node network configuration
       • Supports examples like static IP and DHCP-style setups
       • Can support more advanced networking concepts (e.g., bonding, VLAN interfaces) depending on the agent config structure
     • MAC address mapping
       • Required so the ISO knows which config applies to which node
       • The single generated ISO contains network config for multiple hosts
       • Nodes apply only the relevant config when their NIC MAC matches

3. Generate the agent ISO

   • Command form (shown in the demo):
     • openshift-install agent create image ...
   • The demo includes debug logging.
   • Outputs include an agent ISO plus typical install outputs such as kubeadmin credentials/kubeconfig.

4. Transfer ISO to the target environment

   • Demo uses scp to place the ISO onto a vSphere datastore
   • The ISO is then mounted to the target VMs.

5. Boot nodes to the ISO

   • The ISO boots into CoreOS/initramfs
   • It runs validation and proceeds with cluster installation.

6. Monitoring

   • The demo shows status checks similar to assisted-installer progress signals (e.g., “bootstrap complete”, “install complete”).
   • It emphasizes validations such as capacity/latency/storage checks similar to assisted installation flows.

---

Compatibility / platform support mentioned

Deployment size notes

• Described as working well for single-node / compact style deployments.
• The speaker questions multi-node support beyond compact, and notes examples typically focus on smaller sets.

Install types and environments

• Works with:
  • Disconnected (platform-none) installs
  • vSphere integrated installs (the demo includes both)

IPI vs UPI

• The speaker indicates (based on testing) that the agent-based installer works with UPI-style flows, particularly in vSphere integrated contexts.
• The speaker states they did not get it working for IPI in their attempt and clarifies it was tested only with non-integrated + vSphere integrated in their work.

Cloud providers / bare metal

• Currently limited to specific environments (future expansion implied, but not enumerated).

---

vSphere-related admin analysis (context that impacts installs)

Although not the main feature demo, the speaker provided substantial guidance relevant to OpenShift on VMware.

Can OpenShift control/manage vSphere affinity/anti-affinity rules?

• No (at least for now).
• Reasons given:
  • OpenShift doesn’t know the desired intent/config of the VMware admin’s environment.
  • Permission model challenges: vCenter permissions for creating/managing those rules are non-trivial.

Recommended approach for resiliency

• Prefer soft anti-affinity over hard rules for control plane nodes so VM rescheduling can recover when host capacity changes.
• Apply similar thinking to infrastructure/ingress/service nodes depending on workload needs.

Zone-based provisioning (tech preview)

• Mentioned as an OpenShift 4.12 tech preview feature (“Zone awareness”).
• Concept is similar to AWS availability zones:
  • Implemented using vSphere host labels
  • Nodes deployed across zones to improve resiliency

Cluster spanning multiple sites

• Guidance emphasizes meeting etcd/control-plane requirements:
  • Ensure latency/networking requirements are appropriate for etcd and control plane scalability
  • High latency reduces etcd scalability

---

Additional technical topic: OpenShift Virtualization tuning guide

A highlighted guide: OpenShift Virtualization tuning and scaling guide.

Key point mentioned

• Scheduler decisions can be influenced by whether container images already exist on a node.

Scaling claim mentioned

• The guide includes tested maximums, with an example stated as 10,000 concurrently running VMs in a single cluster.

Tuning guidance

• Performance tuning should be done carefully with baselines and change-by-change measurement.

---

Network topic: OVN-Kubernetes vs OpenShift SDN (policy guidance)

Default SDN behavior

• For OpenShift 4.12, OVN-Kubernetes becomes the default SDN (noted as default since 4.9/4.10 in some cases earlier).
• Guidance: Use the default unless you have a specific reason not to.

Reasons to choose OVN-Kubernetes

• IPv6
• IPsec encryption at the SDN layer

Migration note

• Converting from OpenShift SDN to OVN-Kubernetes is described as one-way conversion.

Deprecation note

• OpenShift SDN is claimed to still be supported.
• Only Courier is noted as deprecated/remove in the 4.12 context.

---

Reviews / guides / tutorials explicitly referenced

• Agent-based installer blog post
  • Created by PM/marketing teams
  • Covers end-to-end steps
  • Speaker recommends it and links it as the source aligned with the demo
• OpenShift Virtualization tuning and scaling guide
  • Emphasizes tested maximums and performance-tuning behaviors
• OpenShift 4.12 zone awareness tech preview
  • Referenced via documentation context and examples
• OVN-Kubernetes vs SDN comparison docs
  • Referenced with feature lists

---

Main speakers / sources

• Speaker: Andrew Sullivan (Red Hat) — host for “Ask an OpenShift Admin (E95)” office hours for this stream
• Other recurring/mentioned person: Johnny (present next week per speaker; not actively speaking in this excerpt)
• Referenced internal sources:
  • OpenShift Product Management/Marketing team blog post authors
  • OpenShift Virtualization engineering team (tuning guide)