cma-operator
is responsible for managing the installation of applications and services on cluster created by Cluster Manager API.
cma-operator
utilizing the below custom resources to manage these applications and comes with a set of default applications installed via the provided SDSAppBundle.
- SDSClusters
- SDSPackageManagers
- SDSApplications
- SDSAppBundles
The default way to deploy CMA-Operator is by the provided helm chart located in the deployment/helm/cma-operator
directory.
Optional steps when using CMA API Proxy:
-
Create proxy DNS name pointing to nginx ingress controller load balancer name or IP, depending on your setup.
-
Update the following entries in the
values.yaml
.cma.enabled: true
cma.apiProxyEndpoint: <dns name from step above>
cma.apiProxyTls: <name of tls secret>
(if using secure) orcma.insecure: true
for insecure.
All new managed clusters will be created with an Ingress and ExternalName service.
Install via helm
-
Install helm chart without default bundles first:
helm install deployments/helm/cma-operator --name cma-operator \ --set bundles.metrics=false \ --set bundles.nginxk8smon=false \ --set bundles.nodelabelbot5000=false
*Alternatively you can update
values.yaml
.After the
cma-operator
pods are running you can upgrade the helm release to include the bundles, see more on SDSAppBundle.helm upgrade cma-operator deployments/helm/cma-operator \ --set bundles.metrics=true \ --set bundles.nginxk8smon=true \ --set bundles.nodelabelbot5000=true
-
Retrieve the
bearertoken
from a GetCluster() call at the CMA level:*Example output:
{ "ok": true, "cluster": { "id": "clusterExampleID", "name": "FooCluster1", "kubeconfig": "apiVersion: v1 clusters: - cluster: certificate-authority-data: <REDACTED> server: https://foocluster1.cloud.com name: foocluster1 contexts: - context: cluster: foocluster1 user: clusterAdmin_foocluster1 name: foocluster1 current-context: foocluster1 kind: Config preferences: {} users: - name: clusterAdmin_foocluster1 user: client-certificate-data: <REDACTED> client-key-data: <REDACTED>, "status": "RUNNING", "bearertoken": "etJhbGciOiJSUzI1NiLsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InNkcy1zYS10b2tlbi1zNzhiOCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJzZHMtc2EiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJlNWQ5OTQ5OF0wZWRmLTExZTktOWNlYi01YTk5N2S2MGU0YWEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6ZGVmYXVsdDpzZHMtc2EifQ.RLkxZI3nPDvPzTzKBkxVR4cX5Jw0PgkYlm2z343SWxOD6Eylf16xHqUfZxaJ5jVPXT80q5alKtjfR8OMNXC93YdmQrZsdRAFuOkwJ8u1Tk1_u7-njvkyKNemB7iqcJRlLPzzlVaR29kC6WpHEWmARZK2jpu7Q7RVc8GNozpmmeCUcHmzllLz2ueoSDdp5pGf2zOpNxOgU_r4eCcj1VuL-i8SVIjfs2iosO1GgP4KU1nwzZESruDnXHw1ZskjBwBb2nordHcYTwzva1S5VRcaGzmv6SqUXyWeuNeZAr-SfLgxF3pU0KXYLUOvSYZQBwvIblu9CubihUojsO9N7_rn4BHAkn_oNADppCvgdQaIjYH35fAW6_86NumD-zLneJ5as32X5IiulwIIqmq4tfo9KkupN3-yMgvPYdzcZq6E5V7l1WbHEY7-uOqkKFcvShZ_0KY7prjgp5BQR3C45IoyIOvd_iKYiPECUum96_RTangKXVK7m77znkGa_zbbVlfyNoDacKtV0TxikRfiv2LrZxfMbp3TsS4vD4-xAWVRoaqvNqJplHQYmVr45BWeVxTnelszvOK1tTvA4r30y9_0lW1CQz1Pj9x9HmNiRZ02ot-OeRHaP367wmh0sr2Kj15JHOMCrTOBT2-5kY-Wf_xlwJ5hli_RWmtFG9EddGa7JTQ" } }
-
Using the "bearertoken" from the output above you can now make api calls to the managed cluster:
- Example:
curl https://<ProxyDNSname>/<clusterName>/api/v1/<API path> -H "Authorization: Bearer <bearerToken>" [--insecure]
- Example:
Manually:
- Run cluster-manager-api (see repo for details)
- Confirm your
kubectl config current-context
is pointing to the cluster you want to test with (ex: minikube) - Run the following command from the root of the cma-operator directory
CMAOPERATOR_CMA_ENDPOINT=localhost:9050 CMAOPERATOR_CMA_INSECURE=true go run cmd/cma-operator/main.go
- Note the environment variables are pointing to the location of the cluster-manager-api from step 1.
Additional flags available: (add to the end of command above)
- Proxy test:
--cma-api-proxy sample.example.com
Using Opctl:
Requirements:
Steps:
- Start cluster-manager-api using opctl (see repo for details).
- Start debug op:
opctl run debug
This will start a container running cma-operator
and referencing a kind cluster created by the cluster-manager-api debug op.
SDSAppBundles are a way to define what helm charts get installed on managed clusters automatically on cluster creation.
The current parameter to define what type of cluster to install on is based on the "Provider". This can be either one or more provider or empty for all providers.
providers: [ aws, azure, vmware, ssh ]
Example yaml for creating a bundle:
apiVersion: cma.sds.samsung.com/v1alpha1
kind: SDSAppBundle
metadata:
name: ingress-controller-bundle
namespace: default
spec:
applications:
- chart:
chartName: nginx-ingress
repository:
name: charts
url: https://github.com/helm/charts/stable
version: 1.1.4
name: sample-ingress-controller
namespace: default
packageManager:
name: ingress-tiller
values: |
controller.metrics.enabled=true,
controller.stats.enabled=true,
k8sversion: 1.10.6
name: ingress-controller-bundle
namespace: default
packagemanager:
image: gcr.io/kubernetes-helm/tiller
name: ingress-tiller
namespace: default
permissions:
clusterWide: false
namespaces:
- default
serviceAccount:
name: ingress-sa
namespace: default
version: v2.11.0
providers: [ 'aws', 'azure' ]