Document "day-2"-operations

awslabs / aws-servicebroker

AWS Service Broker

Apache License 2.0

468 stars 132 forks source link

Document "day-2"-operations #105

Open trondhindenes opened 5 years ago

trondhindenes commented 5 years ago

We're considering Service Broker on Kubernetes, but after researching it, there's a bunch of documentation that I'm finding I need:

How to sync ClusterServiceClass after I've updated templates in S3 - does this happen automatically?
Correct procedures to delete a ClusterServiceClass (guessing there's a link between DynamoDB and CRDs (and possibly even also the etcd instance for the Service Broker itself)
Troubleshooting (what do do when a ClusterServiceClass doesn't show up in Kubernetes)
How to create custom definitions - I'm testing out if it's feasable to create custom stuff based on custom Cloudformation templates, and am struggling. The schemas are complex, and there's a lot of overlap. Precise documentation of the "main" and "spec" file syntax would be welcome.

chiefy commented 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?

trondhindenes commented 5 years ago

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.

mixja commented 5 years ago

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...