In 10/2018 Chris Hein introduced the AWS Service Operator (ASO) project. We reviewed the feedback from the community and stakeholders and in 08/2019 decided to relaunch ASO as a first-tier open source project with concrete commitments from the container service team. In this process, we renamed the project to AWS Controllers for Kubernetes (ACK).
The tenets for the relaunch were:
- ACK is a community-driven project, based on a governance model defining roles and responsibilities.
- ACK is optimized for production usage with full test coverage including performance and scalability test suites.
- ACK strives to be the only codebase exposing AWS services via a Kubernetes operator.
Since then, we worked on design issues and gathering feedback around which services to prioritize.
Existing custom controllers
AWS service teams use custom controllers, webhooks, and operators for different use cases and based on different approaches. Examples include:
- SageMaker operator, allowing to use SageMaker from Kubernetes
- App Mesh controller, managing App Mesh resources from Kubernetes
- EKS Pod Identity Webhook, providing IAM roles for service accounts functionality
While the autonomy in the different teams and project allows for rapid iterations and innovations, there are some drawbacks associated with it:
- The UX differs and that can lead to frustration when adopting an offering.
- A consistent quality bar across the different offerings is hard to establish and to verify.
- It’s wasteful to re-invent the plumbing and necessary infrastructure (testing, etc.).
Above is the motivation for our 3rd tenet: we want to make sure that there is a common framework, implementing good practices as put forward, for example, in the Operator Developer Guide or in the Programming Kubernetes book.
Outside of AWS, there are projects that share similar goals we have with the ASO, for example: