Common recommendations and suggestions
Any recommendations or best practices suggested by the Kubernetes community, such as how to develop Operator pattern solutions or how to are good recommendations for those who are looking to build operator projects with operator-sdk. Also, see Operator Best Practices. However, here are some common recommendations.
Common Recommendations
Building your own operator commonly involves extending the Kubernetes API itself. It is helpful to understand exactly how Custom Resource Definitions interact with the Kubernetes API. Also, the Kubebuilder documentation on may be helpful to better understand these concepts as they relate to operators.
- Provide the images and tags used by the operator solution via environment variables in the :
- Manage your solutions using Status Conditionals
- Use when/if required
- Cover the project with tests/CI to ensure its quality:
- For any language-based operator, you can use Scorecard to implement functional tests
- For Ansible-based operators, you can also use , an Ansible testing framework. For further information see Testing with Molecule
- For Helm-based operators, you can also use
- Ensure that you checked the Can I customize the projects initialized with operator-sdk? and understand the before starting to do your customizations as please you on top.
- Optimize manager resource values in according to project requirements. It is recommended to define resources limits in order to follow good practices and for security reasons. More info: Managing Resources for Containers and .
- Look for in the source code generated by the CLI to ensure that you follow all suggested customizations.