Instruction file imported from nocentino/sql-on-k8s-operator (
.github/instructions/sql-on-k8s-operator.instructions.md). Copyright stays with the author.
sql-on-k8s-operator - Project-Specific Copilot Instructions
These instructions are specific to the sql-on-k8s-operator project and supplement the default repository-wide Copilot instructions.
This Project
This is a Kubernetes operator for managing SQL Server resources on Kubernetes.
- API group/domain:
sql.mssql.microsoft.com - Version:
v1alpha1 - Kinds:
SQLServerInstance— standalone SQL Server instance (StatefulSet + PVC + Services)SQLServerAvailabilityGroup— SQL Server Always On AG across multiple replicas
- Webhooks: Validation-only (no defaulting, no conversion). Both kinds have a
ValidatingWebhook. internal/sqlutil/: Shared helpers for SQL Server connectivity (connection strings, query helpers). Prefer this package over inline SQL logic in controllers.
Project Structure
Single-group layout (default):
cmd/main.go Manager entry (registers controllers/webhooks)
api/<version>/*_types.go CRD schemas (+kubebuilder markers)
api/<version>/zz_generated.* Auto-generated (DO NOT EDIT)
internal/controller/* Reconciliation logic
internal/webhook/<version>/* Validation webhooks
config/crd/bases/* Generated CRDs (DO NOT EDIT)
config/rbac/role.yaml Generated RBAC (DO NOT EDIT)
config/samples/* Example CRs (edit these)
Makefile Build/test/deploy commands
PROJECT Kubebuilder metadata Auto-generated (DO NOT EDIT)
Critical Rules
Never Edit These (Auto-Generated)
config/crd/bases/*.yaml- frommake manifestsconfig/rbac/role.yaml- frommake manifestsconfig/webhook/manifests.yaml- frommake manifests**/zz_generated.*.go- frommake generatePROJECT- fromkubebuilder [OPTIONS]
Never Remove Scaffold Markers
Do NOT delete // +kubebuilder:scaffold:* comments. CLI injects code at these markers.
Keep Project Structure
Do not move files around. The CLI expects files in specific locations.
Always Use CLI Commands
Always use kubebuilder create api and kubebuilder create webhook to scaffold. Do NOT create files manually.
E2E Tests Require an Isolated Kind Cluster
The e2e tests are designed to validate the solution in an isolated environment (similar to GitHub Actions CI). Ensure you run them against a dedicated Kind cluster (not your “real” dev/prod cluster).
After Making Changes
After editing *_types.go or markers:
make manifests # Regenerate CRDs/RBAC from markers
make generate # Regenerate DeepCopy methods
After editing *.go files:
make lint-fix # Auto-fix code style
make test # Run unit tests
CLI Commands Cheat Sheet
Create API (your own types)
kubebuilder create api --group <group> --version <version> --kind <Kind>
Deploy Image Plugin (scaffold to deploy/manage ANY container image)
Generate a controller that deploys and manages a container image (nginx, redis, memcached, your app, etc.):
# Example: deploying memcached
kubebuilder create api --group example.com --version v1alpha1 --kind Memcached \
--image=memcached:alpine \
--plugins=deploy-image.go.kubebuilder.io/v1-alpha
Scaffolds good-practice code: reconciliation logic, status conditions, finalizers, RBAC. Use as a reference implementation.
Create Webhooks
# Validation + defaulting
kubebuilder create webhook --group <group> --version <version> --kind <Kind> \
--defaulting --programmatic-validation
# Conversion webhook (for multi-version APIs)
kubebuilder create webhook --group <group> --version v1 --kind <Kind> \
--conversion --spoke v2
Controller for Core Kubernetes Types
# Watch Pods
kubebuilder create api --group core --version v1 --kind Pod \
--controller=true --resource=false
# Watch Deployments
kubebuilder create api --group apps --version v1 --kind Deployment \
--controller=true --resource=false
Controller for External Types (e.g., from other operators)
Watch resources from external APIs (cert-manager, Argo CD, Istio, etc.):
# Example: watching cert-manager Certificate resources
kubebuilder create api \
--group cert-manager --version v1 --kind Certificate \
--controller=true --resource=false \
--external-api-path=github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1 \
--external-api-domain=io \
--external-api-module=github.com/cert-manager/cert-manager
Note: Use --external-api-module=<module>@<version> only if you need a specific version. Otherwise, omit @<version> to use what's in go.mod.
Webhook for External Types
# Example: validating external resources
kubebuilder create webhook \
--group cert-manager --version v1 --kind Issuer \
--defaulting \
--external-api-path=github.com/cert-manager/cert-manager/pkg/apis/certmanager/v1 \
--external-api-domain=io \
--external-api-module=github.com/cert-manager/cert-manager
Testing & Development
make test # Run unit tests (uses envtest: real K8s API + etcd)
make run # Run locally (uses current kubeconfig context)
Tests use Ginkgo + Gomega (BDD style). Check suite_test.go for setup.
Deployment Workflow
# 1. Regenerate manifests
make manifests generate
# 2. Build & deploy
export IMG=<registry>/<project>:tag
make docker-build docker-push IMG=$IMG # Or: kind load docker-image $IMG --name <cluster>
make deploy IMG=$IMG
# 3. Test
kubectl apply -k config/samples/
# 4. Debug
kubectl logs -n <project>-system deployment/<project>-controller-manager -c manager -f
API Design
Key markers for api/<version>/*_types.go:
// +kubebuilder:object:root=true
// +kubebuilder:subresource:status
// +kubebuilder:resource:scope=Namespaced
// +kubebuilder:printcolumn:name="Status",type=string,JSONPath=".status.conditions[?(@.type=='Ready')].status"
// On fields:
// +kubebuilder:validation:Required
// +kubebuilder:validation:Minimum=1
// +kubebuilder:validation:MaxLength=100
// +kubebuilder:validation:Pattern="^[a-z]+$"
// +kubebuilder:default="value"
- Use
metav1.Conditionfor status (not custom string fields) - Use predefined types:
metav1.Timeinstead ofstringfor dates - Follow K8s API conventions: Standard field names (
spec,status,metadata)
Controller Design
RBAC markers in internal/controller/*_controller.go:
// +kubebuilder:rbac:groups=mygroup.example.com,resources=mykinds,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=mygroup.example.com,resources=mykinds/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=mygroup.example.com,resources=mykinds/finalizers,verbs=update
// +kubebuilder:rbac:groups=events.k8s.io,resources=events,verbs=create;patch
// +kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete
Implementation rules:
- Idempotent reconciliation: Safe to run multiple times
- Re-fetch before updates:
r.Get(ctx, req.NamespacedName, obj)beforer.Updateto avoid conflicts - Structured logging:
log := log.FromContext(ctx); log.Info("msg", "key", val) - Owner references: Enable automatic garbage collection (
SetControllerReference) - Watch secondary resources: Use
.Owns()or.Watches(), not justRequeueAfter - Finalizers: Clean up external resources (buckets, VMs, DNS entries)
Logging
Follow Kubernetes logging message style guidelines:
- Start from a capital letter
- Do not end the message with a period
- Active voice: subject present (
"Deployment could not create Pod") or omitted ("Could not create Pod") - Past tense:
"Could not delete Pod"not"Cannot delete Pod" - Specify object type:
"Deleted Pod"not"Deleted" - Balanced key-value pairs
log.Info("Starting reconciliation")
log.Info("Created Deployment", "name", deploy.Name)
log.Error(err, "Failed to create Pod", "name", name)
Webhooks
- This project uses validation-only webhooks (
--programmatic-validation). Do not add defaulting or conversion unless explicitly required. - When
--forceis used: Backup custom logic first, then restore after scaffolding - For multi-version APIs: Use hub-and-spoke pattern (
--conversion --spoke v2)- Hub version: Usually oldest stable version (v1)
- Spoke versions: Newer versions that convert to/from hub (v2, v3)
- Example:
--group crew --version v1 --kind Captain --conversion --spoke v2(v1 is hub, v2 is spoke)
Learning from Examples
The deploy-image plugin scaffolds a complete controller following good practices. Use it as a reference implementation:
kubebuilder create api --group example --version v1alpha1 --kind MyApp \
--image=<your-image> --plugins=deploy-image.go.kubebuilder.io/v1-alpha
Generated code includes: status conditions (metav1.Condition), finalizers, owner references, events, idempotent reconciliation.
Distribution Options
Option 1: YAML Bundle (Kustomize)
# Generate dist/install.yaml from Kustomize manifests
make build-installer IMG=<registry>/<project>:tag
Key points:
- The
dist/install.yamlis generated from Kustomize manifests (CRDs, RBAC, Deployment) - Commit this file to your repository for easy distribution
- Users only need
kubectlto install (no additional tools required)
Example: Users install with a single command:
kubectl apply -f https://raw.githubusercontent.com/<org>/<repo>/<tag>/dist/install.yaml
Option 2: Helm Chart
kubebuilder edit --plugins=helm/v2-alpha # Generates dist/chart/ (default)
kubebuilder edit --plugins=helm/v2-alpha --output-dir=charts # Generates charts/chart/
For development:
make helm-deploy IMG=<registry>/<project>:<tag> # Deploy manager via Helm
make helm-deploy IMG=$IMG HELM_EXTRA_ARGS="--set ..." # Deploy with custom values
make helm-status # Show release status
make helm-uninstall # Remove release
make helm-history # View release history
make helm-rollback # Rollback to previous version
For end users/production:
helm install my-release ./<output-dir>/chart/ --namespace <ns> --create-namespace
Important: If you add webhooks or modify manifests after initial chart generation:
- Backup any customizations in
<output-dir>/chart/values.yamland<output-dir>/chart/manager/manager.yaml - Re-run:
kubebuilder edit --plugins=helm/v2-alpha --force(use same--output-dirif customized) - Manually restore your custom values from the backup
Publish Container Image
export IMG=<registry>/<project>:<version>
make docker-build docker-push IMG=$IMG
References
Essential Reading
- Kubebuilder Book: https://book.kubebuilder.io (comprehensive guide)
- controller-runtime FAQ: https://github.com/kubernetes-sigs/controller-runtime/blob/main/FAQ.md (common patterns and questions)
- Good Practices: https://book.kubebuilder.io/reference/good-practices.html (why reconciliation is idempotent, status conditions, etc.)
- Logging Conventions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md#message-style-guidelines (message style, verbosity levels)
API Design & Implementation
- API Conventions: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
- Operator Pattern: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
- Markers Reference: https://book.kubebuilder.io/reference/markers.html
Tools & Libraries
- controller-runtime: https://github.com/kubernetes-sigs/controller-runtime
- controller-tools: https://github.com/kubernetes-sigs/controller-tools
- Kubebuilder Repo: https://github.com/kubernetes-sigs/kubebuilder