The Service Mesh SDK
Autopilot is an SDK and toolkit for developing and deploying service mesh operators.
Autopilot generates scaffolding, builds, and deploys Operators which run against a local or remote Kubernetes cluster installed with a Service Mesh.
Autopilot generated code and libraries provide an easy way to automate configuration and monitoring of a service mesh (and other Kubernetes/infra resources) via the Kubernetes Operator pattern.
Installation | Documentation | Blog | Slack | Twitter
How does it work?
Developers define an autopilot.yaml
and autopilot-operator.yaml
which specify the skeleton and configuration of an Autopilot Operator.
Autopilot makes use of these files to (re-)generate the project skeleton, build, deploy, and manage the lifecycle of the operator via the ap
CLI.
Users place their API in a generated spec.go
file, and business logic in generated worker.go
files. Once these files have been modified, they will not be overwritten by ap generate
.
How is it different from SDKs like Operator Framework and Kubebuilder?
The Operator Framework and kubebuilder are open-ended SDKs that take a far less opinionated approach to building Kubernetes software.
Autopilot provides a more opinionated control loop via a generated scheduler that implements the Controller-Runtime Reconciler interface, for which users write stateless Work functions for various states of their top-level CRD. State information is stored on the status of the CRD, promoting a stateless design for Autopilot operators.
Autopilot additionally provides primitives, generated code, and helper functions for interacting with a variery of service meshes. While Autopilot can be used to build operators that do not configure or monitor a mesh, much of Autopilot’s design has been oriented to facilitate easy integration with popular service meshes.
Finally, Autopilot favors simplicity over flexibility, though it is the intention of the project to support the vast majority of DevOps workflows built on top of Kubernetes+Service mesh.
Getting Started
The Getting Started Tutorial provides the best entrypoint to begin understanding and using Autopilot.
Next Steps
- Join us on our Slack channel: https://slack.solo.io/
- Follow us on Twitter: https://twitter.com/soloio_inc
- Check out the docs: https://docs.solo.io/autopilot/latest
- Contribute to the Docs
Thanks
Autopilot would not be possible without the valuable open-source work of projects in the community.
Autopilot has leveraged inspiration and libraries from the following Kubernetes projects:
- Flagger - a robust, feature-rich service mesh operator which deploys canaries. Flagger has helped pioneer the service mesh operator space.
- Controller Runtime - Excellent libraries for building k8s controllers. Many of
- Operator Framework - An SDK for building generalized k8s operators. The source of much inspiration for Autopilot.
Roadmap
- Support for managing multiple (remote) clusters.
- GitOps integrations ootb
- Support opaque user config added in autopilot-operator.yaml
- validate method for project config
- check operatorName is kube compliant
- apiVerson, kind, phases are correct
- customParameters
- final phase with i/o
- Builder funcs for service mesh types (VirtualServices, Gateways, etc.)
ap undeploy
command (undeploy / delete all deployed resources)- includes label all resources for easy list/delete
- Expose garbage collection func to workers
- rollback the phase when something ensure fails? (option in config)
- Support Operators with multiple top-level crds
- Language-agnostic gRPC Worker interface
- OpenAPI schema generation
- interactive cli
- automatic metrics for worker syncs
- automatic traces for worker syncs
- option to make workers persistent