The Kubernetes platform.
The Package manager.
The Open Service Broker.
When readying a Workflow deployment for production workloads, there are some additional recommendations.
In production, persistent storage can be achieved by running an external object store. For users on AWS, GCE/GKE or Azure, the convenience of Amazon S3, Google GCS or Microsoft Azure Storage makes the prospect of running a Storage-less Workflow cluster quite reasonable. For users who have restriction on using external object storage using swift object storage can be an option.
Running a Workflow cluster without Storage provides several advantages:
See Configuring Object Storage for details on removing this operational complexity.
There are some additional security-related considerations when running Workflow in production. See [Security Considerations] for details.
By default, registration with the Workflow controller is in "admin_only" mode. The first user
to run a
drycc register command becomes the initial "admin" user, and registrations after that
are disallowed unless requested by an admin.
Please see the following documentation to learn about changing registration mode:
It is also recommended to disable signups for the Grafana dashboards.
Please see the following documentation to learn about disabling Grafana signups:
If your cluster has RBAC amongst your authorization modes (
$ kubectl api-versions should contains
rbac.authorization.k8s.io) it may be necessary to enable RBAC in Workflow.
This can be achieved by setting
use_rbac in the
global section of
true, or by adding
--set=global.use_rbac=true to the
$ helm install/upgrade command.
RBAC support was announced in Kubernetes-1.5 and is enabled by default if:
- your Kubernetes cluster is in GKE
- your Kubernetes cluster built with kubeadm
Note: helm may need to be given specific permissions under RBAC if not already done.
Attention: Azure ACS Kubernetes clusters are not RBAC-enabled for today due to lack in authentication strategy. Feel free to watch this PR for more details.