|
| 1 | +# Feature Gates for Kubebuilder |
| 2 | + |
| 3 | +This document describes the feature gates functionality implemented in Kubebuilder, which allows developers to mark fields in their API types as belonging to specific feature gates. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +Feature gates provide a way to enable or disable experimental features in your CRDs, similar to how Kubernetes core types handle feature gates. This allows for: |
| 8 | + |
| 9 | +- Gradual rollout of new features |
| 10 | +- A/B testing of experimental functionality |
| 11 | +- Safe deprecation of features |
| 12 | +- Better control over API stability |
| 13 | + |
| 14 | +## Usage |
| 15 | + |
| 16 | +### 1. Marking Fields with Feature Gates |
| 17 | + |
| 18 | +In your API types, you can mark fields with feature gate annotations: |
| 19 | + |
| 20 | +```go |
| 21 | +// MyResourceSpec defines the desired state of MyResource |
| 22 | +type MyResourceSpec struct { |
| 23 | + // Standard field |
| 24 | + Name string `json:"name"` |
| 25 | + |
| 26 | + // Experimental field that requires the "experimental-feature" gate |
| 27 | + // +feature-gate experimental-feature |
| 28 | + ExperimentalField string `json:"experimentalField,omitempty"` |
| 29 | + |
| 30 | + // Another experimental field |
| 31 | + // +feature-gate another-feature |
| 32 | + AnotherField int `json:"anotherField,omitempty"` |
| 33 | +} |
| 34 | +``` |
| 35 | + |
| 36 | +### 2. Running with Feature Gates |
| 37 | + |
| 38 | +When you run your controller, you can enable or disable feature gates: |
| 39 | + |
| 40 | +```bash |
| 41 | +# Enable all feature gates |
| 42 | +./manager --feature-gates=experimental-feature,another-feature |
| 43 | + |
| 44 | +# Enable some gates and disable others |
| 45 | +./manager --feature-gates=experimental-feature=true,another-feature=false |
| 46 | + |
| 47 | +# Disable a specific gate |
| 48 | +./manager --feature-gates=experimental-feature=false |
| 49 | +``` |
| 50 | + |
| 51 | +### 3. Feature Gate Discovery |
| 52 | + |
| 53 | +Kubebuilder automatically discovers feature gates from your API types and generates validation code. The available feature gates are listed in the help text: |
| 54 | + |
| 55 | +```bash |
| 56 | +./manager --help |
| 57 | +``` |
| 58 | + |
| 59 | +You'll see output like: |
| 60 | +``` |
| 61 | +--feature-gates string A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: experimental-feature, another-feature |
| 62 | +``` |
| 63 | + |
| 64 | +## Implementation Details |
| 65 | + |
| 66 | +### Feature Gate Parsing |
| 67 | + |
| 68 | +The feature gate string follows this format: |
| 69 | +- `feature1` - enables feature1 (default) |
| 70 | +- `feature1=true` - explicitly enables feature1 |
| 71 | +- `feature1=false` - explicitly disables feature1 |
| 72 | +- `feature1,feature2=false,feature3` - mixed enabled/disabled gates |
| 73 | + |
| 74 | +### Marker Parsing |
| 75 | + |
| 76 | +Kubebuilder scans your API types for markers in the format: |
| 77 | +``` |
| 78 | +// +feature-gate gate-name |
| 79 | +``` |
| 80 | + |
| 81 | +These markers are found in: |
| 82 | +- Struct field comments |
| 83 | +- Function comments |
| 84 | +- Type comments |
| 85 | + |
| 86 | +### Validation |
| 87 | + |
| 88 | +The controller validates that: |
| 89 | +1. All specified feature gates are valid (exist in the codebase) |
| 90 | +2. Feature gate values are properly formatted |
| 91 | +3. No duplicate or conflicting gate specifications |
| 92 | + |
| 93 | +## Examples |
| 94 | + |
| 95 | +### Basic Example |
| 96 | + |
| 97 | +```go |
| 98 | +// api/v1/myresource_types.go |
| 99 | +type MyResourceSpec struct { |
| 100 | + // Standard field |
| 101 | + Name string `json:"name"` |
| 102 | + |
| 103 | + // Experimental field |
| 104 | + // +feature-gate alpha-feature |
| 105 | + AlphaField string `json:"alphaField,omitempty"` |
| 106 | +} |
| 107 | +``` |
| 108 | + |
| 109 | +### Advanced Example |
| 110 | + |
| 111 | +```go |
| 112 | +// api/v1/complexresource_types.go |
| 113 | +type ComplexResourceSpec struct { |
| 114 | + // Standard fields |
| 115 | + Name string `json:"name"` |
| 116 | + Replicas int32 `json:"replicas"` |
| 117 | + |
| 118 | + // Beta feature |
| 119 | + // +feature-gate beta-feature |
| 120 | + BetaField string `json:"betaField,omitempty"` |
| 121 | + |
| 122 | + // Alpha feature |
| 123 | + // +feature-gate alpha-feature |
| 124 | + AlphaField string `json:"alphaField,omitempty"` |
| 125 | + |
| 126 | + // Experimental feature |
| 127 | + // +feature-gate experimental-feature |
| 128 | + ExperimentalField string `json:"experimentalField,omitempty"` |
| 129 | +} |
| 130 | +``` |
| 131 | + |
| 132 | +Running with different configurations: |
| 133 | + |
| 134 | +```bash |
| 135 | +# Enable all features |
| 136 | +./manager --feature-gates=alpha-feature,beta-feature,experimental-feature |
| 137 | + |
| 138 | +# Enable only beta features |
| 139 | +./manager --feature-gates=beta-feature |
| 140 | + |
| 141 | +# Disable experimental features |
| 142 | +./manager --feature-gates=alpha-feature,beta-feature,experimental-feature=false |
| 143 | +``` |
| 144 | + |
| 145 | +## Best Practices |
| 146 | + |
| 147 | +1. **Use descriptive gate names**: Choose names that clearly indicate what the feature does |
| 148 | +2. **Document your gates**: Add comments explaining what each feature gate enables |
| 149 | +3. **Gradual rollout**: Start with alpha features, then beta, then stable |
| 150 | +4. **Consistent naming**: Use kebab-case for feature gate names |
| 151 | +5. **Validation**: Always validate feature gate inputs in your controllers |
| 152 | + |
| 153 | +## Migration Guide |
| 154 | + |
| 155 | +### From No Feature Gates |
| 156 | + |
| 157 | +1. Add feature gate markers to your experimental fields |
| 158 | +2. Rebuild your project: `make manifests` |
| 159 | +3. Update your deployment to include the `--feature-gates` flag |
| 160 | +4. Test with different gate combinations |
| 161 | + |
| 162 | +### To Stable Features |
| 163 | + |
| 164 | +When a feature is ready for stable release: |
| 165 | +1. Remove the feature gate marker |
| 166 | +2. Update documentation |
| 167 | +3. Consider the field stable and always available |
| 168 | + |
| 169 | +## Troubleshooting |
| 170 | + |
| 171 | +### Common Issues |
| 172 | + |
| 173 | +1. **Unknown feature gate**: Make sure the gate name matches exactly in your code |
| 174 | +2. **Invalid format**: Check that your feature gate string follows the correct format |
| 175 | +3. **Missing validation**: Ensure your controller validates feature gates before use |
| 176 | + |
| 177 | +### Debugging |
| 178 | + |
| 179 | +Enable verbose logging to see feature gate processing: |
| 180 | + |
| 181 | +```bash |
| 182 | +./manager --feature-gates=your-gate --v=2 |
| 183 | +``` |
| 184 | + |
| 185 | +## Future Enhancements |
| 186 | + |
| 187 | +Planned improvements include: |
| 188 | +- CRD schema modification based on enabled gates |
| 189 | +- Automatic documentation generation |
| 190 | +- Integration with controller-runtime feature gates |
| 191 | +- Webhook validation based on feature gates |
0 commit comments