Manage your OpenStack resources from Kubernetes with ORC

Managing OpenStack resources efficiently can be complex, especially when striving for cloud-native agility and GitOps workflows. In this talk, we'll introduce the OpenStack Resource Controller (ORC), a powerful solution combining the benefits of Kubernetes Custom Resource Definitions (CRDs) and controllers with OpenStack’s rich and mature APIs and application ecosystem. We'll explore ORC's fundamental "raison d'être," highlighting how it directly addresses common provisioning pain points many developers and operators face. We’ll compare ORC against “the competition”, exploring both its strengths and weaknesses. Discover its core goals, design philosophy, and how ORC simplifies the declarative management of your OpenStack infrastructure, enabling seamless resource orchestration for modern cloud-native applications.

Transcript

1. Martin André Red Hat Manage your OpenStack resources from Kubernetes with ORC Stephen Finucane Red Hat
2. Introduction Our backgrounds • Historical contributors to TripleO, Kolla, OpenStackSDK, OpenStackClient • Current contributors and maintainers of CAPO, Gophercloud and more
3. Introduction OpenStack Resource Controller • A set of kubernetes controllers and CRDs for managing OpenStack resources • Provides a declarative API (like Kubernetes) • Kubernetes-native • Builds on Gophercloud, the Go OpenStack SDK
5. Plus précisément In more details
6. In more details Quick history • Prototype to check viability • Incubated in Cluster API Provider OpenStack (CAPO) Developed the existing structure of ORC • Split out as a 1.0, containing only the image controller • Quickly followed by a 2.0, adding new controllers New major version because we are strict about semver.
7. In more details Design choices • API follows the k8s conventions • Baked in dependency management, at creation and deletion • Deterministic, when possible • Not mapping the OpenStack API 1 to 1 • No unnecessary API calls to OpenStack: Does not periodically poll OpenStack Reacts to changes to the Kubernetes objects
8. In more details Managed vs Unmanaged resources • Reference on resource: Always by their kubernetes name, never by their OpenStack ID • For a dependency relationship, we need an existing object in ORC • Import existing resources into ORC as unmanaged resource Typically resources created by admin (flavors, provider networks) • ORC won’t modify those resources
9. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
10. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
11. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
12. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
13. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
14. In more details Simple example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Network metadata: name: minimal-network spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: {}
15. In more details Simple example $ openstack network create minimal-network Equivalent to: Except that kubernetes ensures the consistency of the system.
16. In more details Slightly more complex example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: minimal-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: networkRef: minimal-network ipVersion: 4 cidr: 192.168.0.0/24
17. In more details Slightly more complex example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: minimal-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: networkRef: minimal-network ipVersion: 4 cidr: 192.168.0.0/24
18. In more details Slightly more complex example apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: minimal-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: managed resource: networkRef: minimal-network ipVersion: 4 cidr: 192.168.0.0/24
19. In more details Slightly more complex example $ openstack subnet create \ --network minimal-network \ --subnet-range 192.168.0.0/24 \ minimal-subnet Equivalent to: Except that kubernetes manages dependencies.
20. In more details Imported resource apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: imported-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: unmanaged import: filter: name: existing-subnet
21. In more details Imported resource apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: imported-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: unmanaged import: filter: name: existing-subnet
22. In more details Imported resource apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: imported-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: unmanaged import: filter: name: existing-subnet
23. In more details Imported resource apiVersion: openstack.k-orc.cloud/v1alpha1 kind: Subnet metadata: name: imported-subnet spec: cloudCredentialsRef: cloudName: openstack secretName: openstack-clouds managementPolicy: unmanaged import: filter: name: existing-subnet
24. À quoi ça sert? How can I use it?
25. How can I use it? GitOps • Reliably manage your infrastructure • Multi-cloud • Integrates with ArgoCD
26. How can I use it? GitOps
27. How can I use it? Orchestrator • Declarative interface • Managing dependencies between resources • Leverage K8s reconcile loop for all of the heavy work • Deployment of infra for complex applications • Possible replacement for Heat
28. How can I use it? Embedded in your project • The original use case • Delegate handling of complex operations (cough…images…cough) • Move logic of resource management away from consumer code • Makes controllers more reliable • Multiple projects already leverage ORC, including CAPO and Red Hat HyperShift
29. How can I use it? openStackImageSpec.Resource = &orc.ImageResourceSpec{ Name: imageName, Content: &orc.ImageContent{ ContainerFormat: "bare", DiskFormat: "qcow2", Download: &orc.ImageContentSourceDownload{ URL: imageURL, Decompress: ptr.To(orc.ImageCompressionGZ), Hash: &orc.ImageHash{ Algorithm: "sha256", Value: imageHash, }, }, }, }
30. La concurrence The competition
31. La concurrence The competition
32. Le domaine The field
33. The field Equivalents for other platforms Each cloud platform has a similar project: • AWS: AWS Controllers for Kubernetes (ACK) • Azure: Azure Service Operator (ASO) • GCP: Google Cloud Connector (KCC) • VMWare: VM Operator
34. The field Crossplane • CNCF project, big community • Cloud agnostic… but each provider still has its own API • The OpenStack provider builds on top of terraform More difficult to implement support for new fields. In ORC, it’s trivial. • ORC provides the equivalent of Crossplane’s Managed Resources • KRO can leverage ORC. It’s similar to Crossplane’s Compositions. • Fits better with the unix philosophy
35. Et maintenant? What now?
36. What now? Status • Controllers available for the core resources • Easy to contribute new controllers: we’ve built a generator. • Small team of maintainers • Improving gophercloud as we go
37. Where you can help • Test and provide feedback • Contribute the controllers you need • The community is asking for helm charts What now? Join us in #gophercloud on kubernetes slack https://k-orc.cloud/
38. THANKS!