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
- Displaying the status of a Managed services template
- Deleting a deployed Managed services template
Deploying a Managed services template
-
Go to your Kubernetes environment that is same as Managed services.
-
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.
-
-
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
-
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
-
-
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.