Skip to content
Go Shell Makefile Dockerfile
Branch: master
Clone or download
Latest commit 80e1f14 Dec 12, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
api/v1 fmt Nov 17, 2019
changelog fix cloudbuild Dec 12, 2019
ci get ci working, publish releases assets (#4) Nov 14, 2019
cli fix inconsistent example.io and examples.io Nov 18, 2019
codegen fix imports in scheduler Nov 15, 2019
docs center Nov 19, 2019
pkg init command does required go get Nov 15, 2019
test small improvement Nov 16, 2019
.gitignore
Makefile deps make target Nov 15, 2019
README.md center Nov 19, 2019
cloudbuild-cache.yaml remove op sdk dependencies, add config for loglevel Nov 14, 2019
cloudbuild.yaml fix cloudbuild Dec 12, 2019
doc.go docs Nov 13, 2019
go.mod add reference section for docs Nov 16, 2019
go.sum add reference section for docs Nov 16, 2019
install_cli.sh Add indent for for-loop for ap versions (#10) Dec 10, 2019

README.md

Autopilot
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

Autopilot

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

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
You can’t perform that action at this time.