Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Red Hat Device Edge

OpenShift Commons
October 25, 2023
110

Red Hat Device Edge

Speaker: Pablo Acevedo, Red Hat

OpenShift Commons

October 25, 2023
Tweet

More Decks by OpenShift Commons

Transcript

  1. CONFIDENTIAL designator V0000000 1 OpenShift Commons 10/25/2023 Red Hat Device

    Edge RHEL and MicroShift Pablo Acevedo MicroShift Optional section marker or title
  2. CONFIDENTIAL designator V0000000 Red Hat’s approach to edge computing Red

    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
  3. CONFIDENTIAL designator V0000000 Deploying and managing workloads in small edge

    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
  4. CONFIDENTIAL designator V0000000 Red Hat platforms for the edge 4

    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. CONFIDENTIAL designator V0000000 rpm-ostree The operating system for enterprise edge

    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
  6. CONFIDENTIAL designator V0000000 Intelligent rollbacks: Greenboot The operating system for

    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
  7. CONFIDENTIAL designator V0000000 FIDO device onboard (FDO) The operating system

    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
  8. CONFIDENTIAL designator V0000000 8 Why MicroShift? Why customers want K8s

    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
  9. CONFIDENTIAL designator V0000000 Kubernetes cluster services Networking | Ingress |

    Storage | Helm Kubernetes Orchestration | Security Linux for edge (*) Security | Containers | VMs Install | Over-the-air-updates Monitoring | Logging Physical | Virtual | Cloud | Edge Kubernetes cluster services Networking | Ingress | Storage | Helm Install | Over-the-air updates | Cluster Operators | Operator Lifecycle Manager Monitoring | Logging | Registry | Authorization | Console | Cloud Integration | VMs Kubernetes Orchestration | Security Linux Security | Containers MicroShift * recommended for edge deployments: Red Hat Enterprise Linux for Edge Images, rpm-ostree, immutable, atomic upgrade, over the air flavour of Red Hat Enterprise Linux. k8s workload k8s workload k8s operators VMs k8s operators VMs Red Hat provides and supports You provide and support MicroShift WHAT MicroShift vs OpenShift (architecturally)
  10. CONFIDENTIAL designator V0000000 MicroShift HOW 10 MicroShift Design Goals ▸

    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
  11. CONFIDENTIAL designator V0000000 MicroShift HOW 11 MicroShift Architecture (RPM-based, embedded

    in rpm-ostree) rpm-ostree image MicroShift binary systemd kube- api kube- cm kube- sched openshift- api openshift- cm kubelet MicroShift State offline images offline manifests CRI-O file system: starts, stops openshift-router pod storage provider (CSI) openshift-dns pod service-ca pod add-on component manifests Add-on components: OS (kernel, user-space, greenboot, …) network provider (CNI) etcd
  12. CONFIDENTIAL designator V0000000 MicroShift HOW 12 MicroShift is Derived from

    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
  13. CONFIDENTIAL designator V0000000 linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 13 Red Hat

    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
  14. CONFIDENTIAL designator V0000000 Red Hat platforms for the edge MicroShift

    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