Managed services Kubernetes resource controller for Managed services templates

The Managed services Kubernetes custom resource definition and controller provides you with the ability to deploy, update (Plan/Apply), and delete Managed services templates instances that use Kubernetes yaml resource files.

The templates in Managed services are declarative Terraform templates that allow you to deploy infrastructure as code. With this capability, a single Kubernetes yaml can be created to deploy a composite application that consists of both Kubernetes deployable resources and traditional infrastructure resources, which are deployed with Terraform in Managed services. A typical containerized application is an example of a Kubernetes deployable resource. Examples of traditional infrastructure resources are virtual machines, storage, and so on.

About the task

The Managed services Kubernetes resource controller deploys the Managed services template and waits for SUCCESS status. If the deployment FAILS, then the controller continues to issue PLAN/APPLY requests until the APPLY request returns with SUCCESS status.

If one or more of the template parameter values are changed, then the controller issues a PLAN/APPLY until the APPLY request returns with a status of SUCCESS.

Before you begin

A role binding must be defined for a user or group to have the authority to create/apply a templates.cloudautomationmgr.ibm.com resource or to deploy a template in Managed services.

The following is an example for the icp:camgroup:operator user group:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
   name: icp:camgroup:operator:template
roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: cam-controller-manager-role
subjects:
- apiGroup: rbac.authorization.k8s.io
   kind: Group
   name: icp:camgroup:operator

Procedure

Deploying a Managed services template

  1. Go to your Kubernetes environment that is same as Managed services.

  2. Create your YAML file. The file allows the definition of the template deployment to be placed under the source control that allows changes to be tracked. An example Managed services Kubernetes resource controller yaml file:

    apiVersion: cloudautomationmgr.ibm.com/v1alpha1
    kind: Template
    metadata:
     name: template-ibmcloud-sample # The name of the resource. This name is used for the Managed services deployed instance name. Therefore, the kubernetes resource name and the Managed services deployed instance name match with each other. 
     namespace: "default"  # Specifies the Kubernetes and Managed services namespace to use for the deployment. 
    spec:
     connection: "IBMCloud"  # It specifies the name of the Managed services cloud connection to use.
     template:
       name: "Virtual Server with SSH key"  # The name of the Managed services template to deploy.
       version: "2.3"  # The version of the Managed services template to deploy
       parameters:
         parameters:
           datacenter: "dal09"
           hostname: "lrhibmcloud1"
           domain: "raleigh.ibm.com"
    
    • parameters - It is the collection of name/value pairs that map to the Managed services Template Input Parameter Key and Value.

       parameters:
         datacenter: "dal09"
         hostname: "lrh1hostname"
      

      The following sharedParameters parameter is an optional parameter and is dependent on the Managed services template that is deployed:

    • sharedParameters - List of Managed services shared parameter data objects to use with the deployed template. For example:

      sharedParameters:
      - name: DefaultNoBastionHostRequired
        dataType: bastionhost
      
    • secretParameters - (Optional) List of Managed services secret parameter data objects to use with the deployed template. For example:

      secretParameters:
      name: vm_password_lrh
      secretKeyRef:
      	name: vm-password-lrh-secret
      	key: password
      

      Where:

      • name is the name of the template parameter.
      • secretKeyRef.name is the name of the Kubernetes secret.
      • secretKeyRef.key is the name of the secret data defined in the secret.
  3. Run the following kubectl command to deploy a Managed services template:

    kubectl create -f <yaml file name>
    

    Note: A template that is deployed by using the Kubernetes controller can be viewed in the deployed template instances page of Managed services user interface.

    After deployment, if you want to modify and do a plan/apply, run the following kubectl command:

    kubectl apply -f <yaml file name>
    

Displaying the status of a Managed services template

  1. Verify the status of a deployed Managed services template by using either of the following commands:

    kubectl describe -f <yaml file name>
    

    or

    kubectl describe templates.cloudautomationmgr.ibm.com nodejs-ibmcloud-test1 -n default
    

    Example:

    Name:         nodejs-ibmcloud-test1
    Namespace:    default
    Labels:       controller-tools.k8s.io=1.0
    API Version:  cloudautomationmgr.ibm.com/v1alpha1
    Kind:         Template
    Metadata:
      Creation Timestamp:  2019-05-29T20:12:06Z
      Finalizers:
        template.cloudautomationmgr.ibm.com
      Generation:        2
      Resource Version:  7528303
      Self Link:         /apis/cloudautomationmgr.ibm.com/v1alpha1/namespaces/default/templates/nodejs-ibmcloud-test1
      UID:               08075b85-824e-11e9-b7be-00163e01cbab
    Spec:
      Connection:  IBMCloud
      Template:
        Name:  Virtual Server with SSH key
        Parameters:
          Parameters:
            Datacenter:      dal09
            Domain:          raleigh.ibm.com
            Hostname:        lrh1hostname
            Public Ssh Key:  ssh-rsa
        Version:             2.3
    Status:
      Action:  CREATE
      Conditions:
        Last Transition Time:  2019-05-29T20:15:41Z
        Reason:                SUCCESS
        Status:                True
        Type:                  CREATE
      Message:
      Outputs:
        Name:    vm_ip
        Type:    string
        Value:   "Public : 9.9.9.9"
      Stack ID:  5ceee797cdb119001c082077
      Status:    SUCCESS
    Events:
      Type    Reason              Age    From                     Message
      ----    ------              ----   ----                     -------
      Normal  CREATE:IN_PROGRESS  5m34s  cam-template-controller  CREATE status changed for default/nodejs-ibmcloud-test1
      Normal  CREATE:SUCCESS      2m1s   cam-template-controller  CREATE status changed for default/nodejs-ibmcloud-test1
    

    The Status fields returned from the kubectl describe command:

    • Action - Last action performed, that is, CREATE, PLAN, APPLY.

    • Message - Last error message, blank if no error message.

    • Stack ID - Managed services stack ID of the deployment.

    • Status - Status of the last action performed.

    • Conditions

      • Last Transition Time - Last update time of the condition.
      • Reason - The status of the Managed services action.
      • Status - It is 'True' when the condition is valid.
      • Type - The type of the condition - the Managed services action (such as CREATE, PLAN, APPLY).
    • Outputs

      • Name - Name of the output parameter.
      • Type - The type of the parameter, that is, string, list, map.
      • Value - The value of the output parameter in json format.
    • The Event fields returned from the kubectl describe command are Type, Reason, Age, and From. Example:

      Type    Reason                Age   From                      Message
      ----    ------                ---   ----                      -------
      Normal  CREATE:IN_PROGRESS    15m   cam-template-controller   CREATE status changed for default/nodejs-ibmcloud-1
      Normal  CREATE:SUCCESS        69s   cam-template-controller   CREATE status changed for default/nodejs-ibmcloud-1
      
  2. Optionally, you can also use Managed services Kubernetes controller startup parameters - controller parameter. They are defined in cam-controller-statefulset.yaml file. The args parameters are specified in the pod definition.

    The -syncPeriod is a controller parameter for the time duration between resource status checks. Value units are 's', 'm', 'h'." (Default is 2m).

    For example:

    • -syncPeriod=2h30m
    • -syncPeriod=300s
    • -syncPeriod=30m

Deleting a deployed Managed services template

If you no longer require the deployed instance of a template, run either of the following commands to delete it:

kubectl delete -f <yaml file name>

or

kubectl delete templates.cloudautomationmgr.ibm.com nodejs-ibmcloud-test1 -n default

Note: The command deletes the Managed services resources for the deployed instance and then the Managed services instance. After the Managed services instance is successfully deleted, the Kubernetes resource that represents the Managed services instance is also deleted.