Open trondhindenes opened 5 years ago
@trondhindenes been messing with this a bit the past week and I can tell you that the broker polls for changes in s3, so if you update a template it picks it up (looks like right now it's hard-coded to every 10 minutes).
I am trying to evaluate this as something our teams could potentially use as a self-service to create resources coupled with their microservices, but I am struggling trying to figure out how the broker can expose errors or issues without having to tail the broker pod's logs?
We ended up building CRDs and the GCP Metacontroller https://github.com/GoogleCloudPlatform/metacontroller coupled with a custom webhook instead - it gives us full control over everything.
For picking up new templates I have found you need to run the following command:
$ svcat sync broker aws-servicebroker --scope cluster
Synchronization requested for broker: aws-servicebroker
Another tip, by default the service catalog does not persist configuration changes, so when deploying this component recommend the following settings:
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm repo update
helm upgrade --install --recreate-pods --wait catalog --namespace catalog svc-cat/catalog \
--set controllerManager.operationPollingMaximumBackoffDuration=60s \
--set apiserver.storage.etcd.persistence.enabled=true
Without the above, if your service catalog API Server pods die you will lose all of your service classes etc...
We're considering Service Broker on Kubernetes, but after researching it, there's a bunch of documentation that I'm finding I need: