Hat Device Edge 2 Regional data center Remote sites Edge devices Traditional applications Artificial intelligence/ machine learning Cloud-native/modern applications Flexibility and freedom to run workloads where they’re needed
devices Red Hat Device Edge 3 Limited resources Workloads need to run in devices with limited available hardware and software resources. Platform and workload lifecycle management anywhere Devices can be in hard to reach locations, have intermittent connectivity, and minimal to no on-site IT expertise. Management of potentially hundreds of thousand devices Makes scaling existing teams and processes while ensuring security an operational challenge. Not your traditional datacenter challenges
Cloud(s) or DC Single-node edge servers Low bandwidth or disconnected sites Regional DC Edge(s) Remote worker nodes Space-constrained environments 3-node clusters Low footprint clusters with high availability Device edge platform Red Hat Enterprise Linux with minimal profile and tooling for Edge devices + MicroShift Cluster management and application deployment Kubernetes node control Control node Worker node C W C C W C W W Red Hat Device Edge C W
5 Immutable OS and stateful config and storage Transactional updates (A → B model) ▸ OS binaries and libraries (/usr*) are immutable and read-only. ▸ State (r/w) is maintained in /var and /etc. ▸ No inbetween state during updates. ▸ Updates are staged in the background and applied upon reboot. ▸ Reboots can be scheduled with maintenance windows to ensure the highest possible uptime. a2 Data and apps a1 a2 Update Data and apps a1 Major release
enterprise edge 6 Additional safeguard for application and OS compatibility Custom health checks can determine if nodes are functioning properly ▸ Health checks are run during the boot process. ▸ If checks fail, a counter will track the number of attempts. ▸ In a failure state, the node will use rpm-ostree to rollback the update. ▸ Examples can include: ◦ Basic name resolution ◦ Service or container status or health a2 Data and apps a1 a2 Update Data and apps a1 a1 a2 a1 a2
for enterprise edge 7 Securing and simplifying device enrollment ▸ Solves the problem of “late binding” devices to a management platform or to load other instructions/secrets. ▸ Cryptographically identifies the system identity and ownership before enrolling and passing configuration and other secrets. ▸ Enables non-technical users to power on the system and walk away. ▸ Available in Red Hat Enterprise Linux 9.0 and 8.6. Ownership voucher Device Manufacturer, SI, central IT Field provisioned FDO backend server
instead of Podman? ▸ Standardizing on K8s for SW lifecycle mgmt. We standardized on K8s as model for packaging, deploying, configuring, and updating software, using k8s API for service definitions with NetworkPolicy to control which apps can talk to each other ▸ Need for orchestration We run a dozen services of many containers each that we need to orchestrate. Docker Swarm is dead and superseded by K8s. ▸ Consistency of dev+ops across all footprints Our service spans across multiple edge tiers and cloud; we need a single development and operations model/system everywhere. ▸ Relying on off-the-shelf K8s services We’re using KubeFlow and need to run KFServing on our devices. ▸ Right-sizing availability and capacity Single node is all we need now. As we grow, we’ll add services / sites that need HA or additional nodes for capacity. We don’t want to have to rewrite/adapt software for that. Market problem (simplified): System builder audience requiring a customizable OS optimized for device edge but wanting to run K8s workloads. Competitive threat (simplified): Customers only want single K8s supplier. Customers prefer low overhead over features. building devices deployed in the field deploying K8s services; clustering for HA or capacity RHEL for the Edge OpenShift ? MicroShift WHY
minimal: core K8s services + few optional add-ons, rest is “user responsibility” ▸ resource-efficient: goal of <2 cores, <2GB RAM, <2GB storage ▸ monolith: atomic start/stop behavior → make control-plane restarts cheap, remove need for orchestration ▸ familiar to Linux admins: use like any other Linux RPM, w/o K8s expertise ▸ usability: minimal knobs w/ auto-configuration, but escape hatches ▸ built for RHEL: leverage RHEL’s edge capabilities, never duplicate ▸ least-privileged: host admin configures resources that MicroShift makes available → no host OS configuration from within cluster ▸ offline-ready: design for offline, firewalled, rarely connected, expensive/slow net
OpenShift openshift-router pod storage provider (CSI) openshift-dns pod service-ca pod Add-on components: OpenShift release image OpenShift component images OpenShift component manifests OpenShift source code references commit of used by embedded in vendored in network provider (CNI) MicroShift binary kube- api kube- cm kube- sched openshift- api openshift- cm kubelet CRI-O add-on component manifests etcd
is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you Optional section marker or title
prototype in space 15 https://endurancein.space/ Worker: 1 Core 8 GB RAM min per node Control: 2 Core 16GB RAM min per node Worker: 1 Core 8 GB RAM min per node Control: 2 Core 16GB RAM min per node
openshift_commons
chriscoyier
csswizardry
danielanewman
vanstee
nonsquared
colly
tammyeverts
mza
iamctodd
bkeepers
