Applications

Procedure

1. Navigate to Home → Projects.
2. Click Create Project.
3. Enter your project details.
4. Click Create.

Procedure

1. Run:

Procedure

1. Navigate to Home → Projects.

2. Select a project to view.

   On this page, click the Resources button to see workloads in the project and click the Dashboard button to see metrics and details about the project.

Procedure

1. To view a list of projects, run:

   $ oc get projects

2. You can change from the current project to a different project for CLI operations. The specified project is then used in all subsequent operations that manipulate project-scoped content:

   $ oc project <project_name>

Procedure

1. Navigate to Home → Projects.
2. Select a project.
3. In the upper right-hand corner of the Project Status menu, click Add, then choose from the provided options.

Procedure

1. Navigate to Home → Projects.
2. Select a project to see its status.

Procedure

1. Run:

   $ oc status

   This command provides a high-level overview of the current project, with its components and their relationships.

Procedure

1. Navigate to Home → Projects.
2. Locate the project that you want to delete from the list of projects.
3. On the far right side of the project listing, select Delete Project from the menu. If you do not have permissions to delete the project, the Delete Project option is grayed out and the option is not clickable.

Procedure

1. Run:

   $ oc delete project <project_name>

Procedure

1. Log in as a user with cluster-admin privileges.

2. Generate the default project template:

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. Use a text editor to modify the generated template.yaml file by adding objects or modifying existing objects.

4. The project template must be created in the openshift-config namespace. Load your modified template:

   $ oc create -f template.yaml -n openshift-config

5. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

6. Update the spec section to include the projectRequestTemplate and name parameters, and set the name of your uploaded project template. The default name is project-request.

   Project configuration resource with custom project template

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. After you save your changes, create a new project to verify that your changes were successfully applied.

Procedure

1. Log in as a user with cluster-admin privileges.

2. View the self-provisioners cluster role binding usage by running the following command:

   $ oc describe clusterrolebinding.rbac self-provisioners
   
   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   Review the subjects in the self-provisioners section.

3. Remove the self-provisioner cluster role from the group system:authenticated:oauth.

   • If the self-provisioners cluster role binding binds only the self-provisioner role to the system:authenticated:oauth group, run the following command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • If the self-provisioners cluster role binding binds the self-provisioner role to more users, groups, or service accounts than the system:authenticated:oauth group, run the following command:

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. Edit the self-provisioners cluster role binding to prevent automatic updates to the role. Automatic updates reset the cluster roles to the default state.

   • To update the role binding using the CLI:

     1. Run the following command:

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. In the displayed role binding, set the rbac.authorization.kubernetes.io/autoupdate parameter value to false, as shown in the following example:

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • To update the role binding by using a single command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. Login as an authenticated user and verify that it can no longer self-provision a project:

   $ oc new-project test
   
   Error from server (Forbidden): You may not request a new project via this API.

   Consider customizing this project request message to provide more helpful instructions specific to your organization.

Procedure

1. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Log in as a user with cluster-admin privileges.

     2. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

2. Update the spec section to include the projectRequestMessage parameter and set the value to your custom message:

   Project configuration resource with custom project request message

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   For example:

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. After you save your changes, attempt to create a new project as a developer or service account that is unable to self-provision projects to verify that your changes were successfully applied.

Procedure

1. Select the Operator to delete. There are two paths to do this:

   • From the Catalog → OperatorHub page:

     1. Scroll or type a keyword into the Filter by keyword box (in this case, jaeger) to find the Operator you want and click on it.
     2. Click Uninstall.

   • From the Catalog → Operator Management page:

     1. Select the namespace where the Operator is installed from the Project list. For cluster-wide Operators, the default is openshift-operators.

     2. From the Operator Subscriptions tab, find the Operator you want to delete (in this example, jaeger) and click the Options menu at the end of its entry.

        
     3. Click Remove Subscription.
2. When prompted by the Remove Subscription window, optionally select the Also completely remove the jaeger Operator from the selected namespace check box if you want all components related to the installation to be removed. This removes the CSV, which in turn removes the Pods, Deployments, CRDs, and CRs associated with the Operator.
3. Select Remove. This Operator will stop running and no longer receive updates.

1. Check the current version of the subscribed Operator (for example, jaeger) in the currentCSV field:

   $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV
     currentCSV: jaeger-operator.v1.8.2

2. Delete the Operator’s Subscription (for example, jaeger):

   $ oc delete subscription jaeger -n openshift-operators
   subscription.operators.coreos.com "jaeger" deleted

3. Delete the CSV for the Operator in the target namespace using the currentCSV value from the previous step:

   $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators
   clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

4. Display the contents of the CatalogSourceConfig resource and review the list of packages in the spec section:

   $ oc get catalogsourceconfig -n openshift-marketplace \
       installed-community-openshift-operators -o yaml

   For example, the spec section might appear as follows:

   Example of CatalogSourceConfig

   spec:
     csDisplayName: Community Operators
     csPublisher: Community
     packages: jaeger,descheduler
     targetNamespace: openshift-operators

5. Remove the Operator from the CatalogSourceConfig in one of two ways:

   • If you have multiple Operators, edit the CatalogSourceConfig resource and remove the Operator’s package:

     $ oc edit catalogsourceconfig -n openshift-marketplace \
         installed-community-openshift-operators

     Remove the package from the packages line, as shown:

     Example of modified packages in CatalogSourceConfig

       packages: descheduler

     Save the change and the marketplace-operator will reconcile the CatalogSourceConfig.

   • If there is only one Operator in the CatalogSourceConfig, you can remove it by deleting the entire CatalogSourceConfig as follows:

     $ oc delete catalogsourceconfig -n openshift-marketplace \
         installed-community-openshift-operators

Procedure

1. Create a new project in the OpenShift Container Platform web console for this procedure. This example uses a project called my-etcd.

2. Navigate to the Catalogs → Installed Operators page. The Operators that have been installed to the cluster by the cluster administrator and are available for use are shown here as a list of ClusterServiceVersions (CSVs). CSVs are used to launch and manage the software provided by the Operator.

   Tip

   You can get this list from the CLI using:

   $ oc get csv

3. On the Installed Operators page, click Copied, and then click the etcd Operator to view more details and available actions:

   Figure 2.6. etcd Operator overview

   

   As shown under Provided APIs, this Operator makes available three new resource types, including one for an etcd Cluster (the EtcdCluster resource). These objects work similar to the built-in native Kubernetes ones, such as Deployments or ReplicaSets, but contain logic specific to managing etcd.

4. Create a new etcd cluster:

   1. In the etcd Cluster API box, click Create New.
   2. The next screen allows you to make any modifications to the minimal starting template of an EtcdCluster object, such as the size of the cluster. For now, click Create to finalize. This triggers the Operator to start up the Pods, Services, and other components of the new etcd cluster.

5. Click the Resources tab to see that your project now contains a number of resources created and configured automatically by the Operator.

   Figure 2.7. etcd Operator resources

   

   Verify that a Kubernetes service has been created that allows you to access the database from other Pods in your project.

6. All users with the edit role in a given project can create, manage, and delete application instances (an etcd cluster, in this example) managed by Operators that have already been created in the project, in a self-service manner, just like a cloud service. If you want to enable additional users with this ability, project administrators can add the role using the following command:

   $ oc policy add-role-to-user edit <user> -n <target_project>

Procedure

1. Create a YAML file for the CR. In the following example definition, the cronSpec and image custom fields are set in a CR of Kind: CronTab. The Kind comes from the spec.kind field of the CRD object.

   Example YAML file for a CR

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   Specify the group name and API version (name/version) from the Custom Resource Definition.

   2

   Specify the type in the CRD.

   3

   Specify a name for the object.

   4

   Specify the finalizers for the object, if any. Finalizers allow controllers to implement conditions that must be completed before the object can be deleted.

   5

   Specify conditions specific to the type of object.

2. After you create the file, create the object:

   $ oc create -f <file_name>.yaml

Procedure

1. To get information on a specific Kind of a CR, run:

   $ oc get <kind>

   For example:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   Resource names are not case-sensitive, and you can use either the singular or plural forms defined in the CRD, as well as any short name. For example:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. You can also view the raw YAML data for a CR:

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   Custom data from the YAML that you used to create the object displays.

Procedure

1. Enable the service catalog API server:

   1. Use the following command to edit the service catalog API server resource:

      $ oc edit servicecatalogapiservers

   2. Under spec, set the managementState field to Managed:

      spec:
        logLevel: Normal
        managementState: Managed

   3. Save the file to apply the changes.

      The Operator installs the service catalog API server component. As of OpenShift Container Platform 4, this component is installed into the openshift-service-catalog-apiserver namespace.

2. Enable the service catalog controller manager:

   1. Use the following command to edit the service catalog controller manager resource:

      $ oc edit servicecatalogcontrollermanagers

   2. Under spec, set the managementState field to Managed:

      spec:
        logLevel: Normal
        managementState: Managed

   3. Save the file to apply the changes.

      The Operator installs the service catalog controller manager component. As of OpenShift Container Platform 4, this component is installed into the openshift-service-catalog-controller-manager namespace.

Procedure

1. Disable the service catalog API server:

   1. Use the following command to edit the service catalog API server resource:

      $ oc edit servicecatalogapiservers

   2. Under spec, set the managementState field to Removed:

      spec:
        logLevel: Normal
        managementState: Removed

   3. Save the file to apply the changes.

2. Disable the service catalog controller manager:

   1. Use the following command to edit the service catalog controller manager resource:

      $ oc edit servicecatalogcontrollermanagers

   2. Under spec, set the managementState field to Removed:

      spec:
        logLevel: Normal
        managementState: Removed

   3. Save the file to apply the changes.

1. Create a namespace.

   1. Navigate in the web console to Administration → Namespaces and click Create Namespace.

   2. Enter openshift-template-service-broker in the Name field and click Create.

      Note

      The namespace must start with openshift-.

2. Navigate to the Catalog → OperatorHub page. Verify that the openshift-template-service-broker project is selected.
3. Select Template Service Broker Operator.
4. Read the information about the Operator and click Install.
5. Review the default selections and click Subscribe.

Procedure

1. Navigate in the web console to Catalog → Installed Operators and select the openshift-template-service-broker project.
2. Select the Template Service Broker Operator.
3. Under Provided APIs, click Create New for Template Service Broker.
4. Review the default YAML and click Create.

5. Verify that the Template Service Broker has started.

   After the Template Service Broker has started, you can view the available template applications by navigating to Catalog → Developer Catalog and selecting the Service Class checkbox. Note that it may take a few minutes for the Template Service Broker to start and the template applications to be available.

   If you do not yet see these Service classes, you can check the status of the following items:

   • Template Service Broker Pod status

     • From the Workloads → Pods page for the openshift-template-service-broker project, verify that the Pod that starts with apiserver- has a status of Running and readiness of Ready.

   • Cluster service broker status

     • From the Catalog → Broker Management → Service Brokers page, verify that the template-service-broker service broker has a status of Ready.

   • Service catalog controller manager Pod logs

     • From the Workloads → Pods page for the openshift-service-catalog-controller-manager project, review the logs for each of the Pods and verify that you see a log entry with the message Successfully fetched catalog entries from broker.

Procedure

1. Create a project.

   1. Navigate in the web console to Home → Projects and click Create Project.
   2. Enter test-postgresql in the Name field and click Create.

2. Create a service instance.

   1. Navigate to the Catalog → Developer Catalog page.
   2. Select the PostgreSQL (Ephemeral) template application and click Create Service Instance.
   3. Review the default selections and set any other required fields, and click Create.

   4. Go to Catalog → Provisioned Services and verify that the postgresql-ephemeral service instance is created and has a status of Ready.

      You can check the progress on the Home → Events page. After a few moments, you should see an event for postgresql-ephemeral with the message "The instance was provisioned successfully".

3. Create a service binding.

   1. From the Provisioned Services page, click postgresql-ephemeral and click Create Service Binding.

   2. Review the default service binding name and click Create.

      This creates a new secret for binding using the name provided.

4. Review the secret that was created.

   1. Navigate to Workloads → Secrets and verify that a secret named postgresql-ephemeral was created.
   2. Click postgresql-ephemeral and review the key-value pairs in the Data section, which are used for binding to other apps.

1. Uninstall the Template Service Broker.

   1. Navigate to Catalog → Installed Operators and select the openshift-template-service-broker project from the drop-down menu.
   2. Click Template Service Broker Operator.
   3. Select the Template Service Broker tab.
   4. Click template-service-broker.
   5. From the Actions drop-down menu, select Delete Template Service Broker.

   6. Click Delete from the confirmation pop-up window.

      The Template Service Broker is now uninstalled, and template applications will soon be removed from the Developer Catalog.

2. Uninstall the Template Service Broker Operator.

   1. Navigate to Catalog → Operator Management and select the openshift-template-service-broker project from the drop-down menu.
   2. Click View subscription for the Template Service Broker Operator.
   3. Select templateservicebroker.
   4. From the Actions drop-down menu, select Remove Subscription.

   5. Verify that the checkbox is checked next to Also completely remove the templateservicebroker Operator from the selected namespace and click Remove.

      The Template Service Broker Operator is no longer installed in your cluster.

1. A user requests the list of available applications from the service catalog using the OpenShift Container Platform web console.
2. The service catalog requests the list of available applications from the OpenShift Ansible Broker.
3. The OpenShift Ansible Broker communicates with a defined container image registry to learn which APBs are available.
4. The user issues a request to provision a specific APB.
5. The OpenShift Ansible Broker fulfills the user’s provision request by invoking the provision method on the APB.

1. Create a namespace.

   1. Navigate in the web console to Administration → Namespaces and click Create Namespace.

   2. Enter openshift-ansible-service-broker in the Name field and openshift.io/cluster-monitoring=true in the Labels field and click Create.

      Note

      The namespace must start with openshift-.

2. Create a cluster role binding.

   1. Navigate to Administration → Role Bindings and click Create Binding.
   2. For the Binding Type, select Cluster-wide Role Binding (ClusterRoleBinding).
   3. For the Role Binding, enter ansible-service-broker in the Name field.
   4. For the Role, select admin.
   5. For the Subject, choose the Service Account option, select the openshift-ansible-service-broker namespace, and enter openshift-ansible-service-broker-operator in the Subject Name field.
   6. Click Create.

3. Create a secret to connect to the Red Hat Container Catalog.

   1. Navigate to Workloads → Secrets. Verify that the openshift-ansible-service-broker project is selected.
   2. Click Create → Key/Value Secret.
   3. Enter asb-registry-auth as the Secret Name.
   4. Add a Key of username and a Value of your Red Hat Container Catalog user name.
   5. Click Add Key/Value and add a Key of password and a Value of your Red Hat Container Catalog password.
   6. Click Create.
4. Navigate to the Catalog → OperatorHub page. Verify that the openshift-ansible-service-broker project is selected.
5. Select OpenShift Ansible Service Broker Operator.
6. Read the information about the Operator and click Install.
7. Review the default selections and click Subscribe.

Procedure

1. Navigate in the web console to Catalog → Installed Operators and select the openshift-ansible-service-broker project.
2. Select the OpenShift Ansible Service Broker Operator.
3. Under Provided APIs, click Create New for Automation Broker.

4. Add the following to the spec field in the default YAML provided:

   registry:
     - name: rhcc
       type: rhcc
       url: https://registry.redhat.io
       auth_type: secret
       auth_name: asb-registry-auth

   This references the secret that was created when installing the OpenShift Ansible Service Broker Operator, which allows you to connect to the Red Hat Container Catalog.

5. Set any additional OpenShift Ansible Broker configuration options and click Create.

6. Verify that the OpenShift Ansible Broker has started.

   After the OpenShift Ansible Broker has started, you can view the available service bundles by navigating to Catalog → Developer Catalog and selecting the Service Class checkbox. Note that it may take a few minutes for the OpenShift Ansible Broker to start and the service bundles to be available.

   If you do not yet see these Service classes, you can check the status of the following items:

   • OpenShift Ansible Broker Pod status

     • From the Workloads → Pods page for the openshift-ansible-service-broker project, verify that the Pod that starts with asb- has a status of Running and readiness of Ready.

   • Cluster service broker status

     • From the Catalog → Broker Management → Service Brokers page, verify that the ansible-service-broker service broker has a status of Ready.

   • Service catalog controller manager Pod logs

     • From the Workloads → Pods page for the openshift-service-catalog-controller-manager project, review the logs for each of the Pods and verify that you see a log entry with the message Successfully fetched catalog entries from broker.

1. Navigate in the web console to Catalog → Installed Operators and select the ansible-service-broker project.
2. Select the OpenShift Ansible Service Broker Operator.
3. On the Automation Broker tab, select ansible-service-broker.

4. On the YAML tab, add or update any OpenShift Ansible Broker configuration options under the spec field.

   For example:

   spec:
     keepNamespace: true
     sandboxRole: edit

5. Click Save to apply these changes.

Procedure

1. Create the role.

   1. Navigate to Administration → Roles and click Create Role.

   2. Replace the YAML in the editor with the following:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: prometheus-k8s
        namespace: openshift-ansible-service-broker
      rules:
      - apiGroups:
        - ""
        resources:
        - services
        - endpoints
        - pods
        verbs:
        - get
        - list
        - watch

   3. Click Create.

2. Create the role binding.

   1. Navigate to Administration → Role Bindings and click Create Binding.
   2. For the Binding Type, select Namespace Role Binding (RoleBinding).
   3. For the Role Binding, enter prometheus-k8s in the Name field and openshift-ansible-service-broker in the Namespace field.
   4. For the Role, select prometheus-k8s.
   5. For the Subject, choose the Service Account option, select the openshift-monitoring namespace, and enter prometheus-k8s in the Subject Name field.
   6. Click Create.

Procedure

1. Create a project.

   1. Navigate in the web console to Home → Projects and click Create Project.
   2. Enter test-postgresql-apb in the Name field and click Create.

2. Create a service instance.

   1. Navigate to the Catalog → Developer Catalog page.
   2. Select the PostgreSQL (APB) service bundle and click Create Service Instance.
   3. Review the default selections and set any other required fields, and click Create.

   4. Go to Catalog → Provisioned Services and verify that the dh-postgresql-apb service instance is created and has a status of Ready.

      You can check the progress on the Home → Events page. After a few moments, you should see an event for dh-postgresql-apb with the message "The instance was provisioned successfully".

3. Create a service binding.

   1. From the Provisioned Services page, click dh-postgresql-apb and click Create Service Binding.

   2. Review the default service binding name and click Create.

      This creates a new secret for binding using the name provided.

4. Review the secret that was created.

   1. Navigate to Workloads → Secrets and verify that a secret named dh-postgresql-apb was created.
   2. Click dh-postgresql-apb and review the key-value pairs in the Data section, which are used for binding to other apps.

1. Uninstall the OpenShift Ansible Broker.

   1. Navigate to Catalog → Installed Operators and select the openshift-ansible-service-broker project from the drop-down menu.
   2. Click OpenShift Ansible Service Broker Operator.
   3. Select the Automation Broker tab.
   4. Click ansible-service-broker.
   5. From the Actions drop-down menu, select Delete Automation Broker.

   6. Click Delete from the confirmation pop-up window.

      The OpenShift Ansible Broker is now uninstalled, and service bundles will soon be removed from the Developer Catalog.

2. Uninstall the OpenShift Ansible Service Broker Operator.

   1. Navigate to Catalog → Operator Management and select the openshift-ansible-service-broker project from the drop-down menu.
   2. Click View subscription for the OpenShift Ansible Service Broker Operator.
   3. Select automationbroker.
   4. From the Actions drop-down menu, select Remove Subscription.

   5. Verify that the checkbox is checked next to Also completely remove the automationbroker Operator from the selected namespace and click Remove.

      The OpenShift Ansible Service Broker Operator is no longer installed in your cluster.

1. The elements of a ReplicationController definition.
2. Triggers for creating a new deployment automatically.
3. The strategy for transitioning between deployments.
4. Lifecycle hooks.

1. Executes any pre lifecycle hook.
2. Scales up the new ReplicationController based on the surge count.
3. Scales down the old ReplicationController based on the max unavailable count.
4. Repeats this scaling until the new ReplicationController has reached the desired replica count and the old ReplicationController has been scaled to zero.
5. Executes any post lifecycle hook.

1. Executes any pre lifecycle hook.
2. Scales down the previous deployment to zero.
3. Executes any mid lifecycle hook.
4. Scales up the new deployment.
5. Executes any post lifecycle hook.

1. Create a YAML file that contains the following field types:

   Example YAML file for a CRD

   apiVersion: apiextensions.k8s.io/v1beta1 1
   kind: CustomResourceDefinition
   metadata:
     name: crontabs.stable.example.com 2
   spec:
     group: stable.example.com 3
     version: v1 4
     scope: Namespaced 5
     names:
       plural: crontabs 6
       singular: crontab 7
       kind: CronTab 8
       shortNames:
       - ct 9

   1

   Use the apiextensions.k8s.io/v1beta1 API.

   2

   Specify a name for the definition. This must be in the <plural-name>.<group> format using the values from the group and plural fields.

   3

   Specify a group name for the API. An API group is a collection of objects that are logically related. For example, all batch objects like Job or ScheduledJob could be in the batch API Group (such as batch.api.example.com). A good practice is to use a fully-qualified-domain name of your organization.

   4

   Specify a version name to be used in the URL. Each API Group can exist in multiple versions. For example: v1alpha, v1beta, v1.

   5

   Specify whether the custom objects are available to a project (Namespaced) or all projects in the cluster (Cluster).

   6

   Specify the plural name to use in the URL. The plural field is the same as a resource in an API URL.

   7

   Specify a singular name to use as an alias on the CLI and for display.

   8

   Specify the kind of objects that can be created. The type can be in CamelCase.

   9

   Specify a shorter string to match your resource on the CLI.

   Note

   By default, a CRD is cluster-scoped and available to all projects.

2. Create the CRD object:

   $ oc create -f <file_name>.yaml

   A new RESTful API endpoint is created at:

   /apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

   For example, using the example file, the following endpoint is created:

   /apis/stable.example.com/v1/namespaces/*/crontabs/...

   You can now use this endpoint URL to create and manage CRs. The object Kind is based on the spec.kind field of the CRD object you created.

Procedure

1. Create a cluster role definition file for the CRD. The cluster role definition is a YAML file that contains the rules that apply to each cluster role. The OpenShift Container Platform controller adds the rules that you specify to the default cluster roles.

   Example YAML file for a cluster role definition

   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1 1
   metadata:
     name: aggregate-cron-tabs-admin-edit 2
     labels:
       rbac.authorization.k8s.io/aggregate-to-admin: "true" 3
       rbac.authorization.k8s.io/aggregate-to-edit: "true" 4
   rules:
   - apiGroups: ["stable.example.com"] 5
     resources: ["crontabs"] 6
     verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7
   ---
   kind: ClusterRole
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: aggregate-cron-tabs-view 8
     labels:
       # Add these permissions to the "view" default role.
       rbac.authorization.k8s.io/aggregate-to-view: "true" 9
       rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10
   rules:
   - apiGroups: ["stable.example.com"] 11
     resources: ["crontabs"] 12
     verbs: ["get", "list", "watch"] 13

   1

   Use the rbac.authorization.k8s.io/v1 API.

   2 8

   Specify a name for the definition.

   3

   Specify this label to grant permissions to the admin default role.

   4

   Specify this label to grant permissions to the edit default role.

   5 11

   Specify the group name of the CRD.

   6 12

   Specify the plural name of the CRD that these rules apply to.

   7 13

   Specify the verbs that represent the permissions that are granted to the role. For example, apply read and write permissions to the admin and edit roles and only read permission to the view role.

   9

   Specify this label to grant permissions to the view default role.

   10

   Specify this label to grant permissions to the cluster-reader default role.

2. Create the cluster role:

   $ oc create -f <file_name>.yaml

Procedure

1. Create a YAML file for the CR. In the following example definition, the cronSpec and image custom fields are set in a CR of Kind: CronTab. The Kind comes from the spec.kind field of the CRD object.

   Example YAML file for a CR

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   Specify the group name and API version (name/version) from the Custom Resource Definition.

   2

   Specify the type in the CRD.

   3

   Specify a name for the object.

   4

   Specify the finalizers for the object, if any. Finalizers allow controllers to implement conditions that must be completed before the object can be deleted.

   5

   Specify conditions specific to the type of object.

2. After you create the file, create the object:

   $ oc create -f <file_name>.yaml

Procedure

1. To get information on a specific Kind of a CR, run:

   $ oc get <kind>

   For example:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   Resource names are not case-sensitive, and you can use either the singular or plural forms defined in the CRD, as well as any short name. For example:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. You can also view the raw YAML data for a CR:

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   Custom data from the YAML that you used to create the object displays.

Procedure

1. Create a YAML file for the CR. In the following example definition, the cronSpec and image custom fields are set in a CR of Kind: CronTab. The Kind comes from the spec.kind field of the CRD object.

   Example YAML file for a CR

   apiVersion: "stable.example.com/v1" 1
   kind: CronTab 2
   metadata:
     name: my-new-cron-object 3
     finalizers: 4
     - finalizer.stable.example.com
   spec: 5
     cronSpec: "* * * * /5"
     image: my-awesome-cron-image

   1

   Specify the group name and API version (name/version) from the Custom Resource Definition.

   2

   Specify the type in the CRD.

   3

   Specify a name for the object.

   4

   Specify the finalizers for the object, if any. Finalizers allow controllers to implement conditions that must be completed before the object can be deleted.

   5

   Specify conditions specific to the type of object.

2. After you create the file, create the object:

   $ oc create -f <file_name>.yaml

Procedure

1. To get information on a specific Kind of a CR, run:

   $ oc get <kind>

   For example:

   $ oc get crontab
   
   NAME                 KIND
   my-new-cron-object   CronTab.v1.stable.example.com

   Resource names are not case-sensitive, and you can use either the singular or plural forms defined in the CRD, as well as any short name. For example:

   $ oc get crontabs
   $ oc get crontab
   $ oc get ct

2. You can also view the raw YAML data for a CR:

   $ oc get <kind> -o yaml

   $ oc get ct -o yaml
   
   apiVersion: v1
   items:
   - apiVersion: stable.example.com/v1
     kind: CronTab
     metadata:
       clusterName: ""
       creationTimestamp: 2017-05-31T12:56:35Z
       deletionGracePeriodSeconds: null
       deletionTimestamp: null
       name: my-new-cron-object
       namespace: default
       resourceVersion: "285"
       selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
       uid: 9423255b-4600-11e7-af6a-28d2447dc82b
     spec:
       cronSpec: '* * * * /5' 1
       image: my-awesome-cron-image 2

   1 2

   Custom data from the YAML that you used to create the object displays.

Procedure

1. Define the quota in a file.

2. Use the file to create the quota and apply it to a project:

   $ oc create -f <file> [-n <project_name>]

   For example:

   $ oc create -f core-object-counts.yaml -n demoproject

Procedure

1. Get the list of quotas defined in the project. For example, for a project called demoproject:

   $ oc get quota -n demoproject
   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. Describe the quota you are interested in, for example the core-object-counts quota:

   $ oc describe quota core-object-counts -n demoproject
   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

1. Edit the Kubernetes controller manager.

   $ oc edit kubecontrollermanager cluster

2. Change the unsupportedconfigOverrides field to have the following settings, specifying the amount of time, in seconds, for the resource-quota-sync-period field:

     unsupportedConfigOverrides:
       extendedArguments:
         resource-quota-sync-period:
         - 60s

Procedure

1. To select projects based on annotations, run the following command:

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   This creates the following ClusterResourceQuota object:

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   The ResourceQuotaSpec object that will be enforced over the selected projects.

   2

   A simple key-value selector for annotations.

   3

   A label selector that can be used to select projects.

   4

   A per-namespace map that describes current quota usage in each selected project.

   5

   The aggregate usage across all selected projects.

   This multi-project quota document controls all projects requested by <user_name> using the default project request endpoint. You are limited to 10 pods and 20 secrets.

2. Similarly, to select projects based on labels, run this command:

   $  oc create clusterresourcequota for-name \ 1
       --project-label-selector=name=frontend \ 2
       --hard=pods=10 --hard=secrets=20

   1

   Both clusterresourcequota and clusterquota are aliases of the same command. for-name is the name of the ClusterResourceQuota object.

   2

   To select projects by label, provide a key-value pair by using the format --project-label-selector=key=value.

   This creates the following ClusterResourceQuota object definition:

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

Procedure

1. To view quotas applied to a project, run:

   $ oc describe AppliedClusterResourceQuota

   For example:

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20

Procedure

1. To idle a single service, run:

   $ oc idle <service>

Procedure

1. Create a file containing a list of the services, each on their own line.

2. Idle the services using the --resource-names-file option:

   $ oc idle --resource-names-file <filename>

Procedure

1. To see what a pruning operation would delete:

   1. Keeping up to three tag revisions, and keeping resources (images, image streams and Pods) younger than sixty minutes:

      $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

   2. Pruning every image that exceeds defined limits:

      $ oc adm prune images --prune-over-size-limit

2. To actually perform the prune operation with the options from the previous step:

   $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

   $ oc adm prune images --prune-over-size-limit --confirm

1. The prune command is run with the --force-insecure option.
2. The provided registry-url is prefixed with the http:// scheme.
3. The provided registry-url is a local-link address or localhost.
4. The configuration of the current user allows for an insecure connection. This can be caused by the user either logging in using --insecure-skip-tls-verify or choosing the insecure connection when prompted.

1. The recommend solution is to secure the registry. Otherwise, you can force the client to use an insecure connection by appending --force-insecure to the command, however this is not recommended.

Procedure

1. Create a new project.

   Use the CLI to create a new memcached-operator project:

   $ mkdir -p $GOPATH/src/github.com/example-inc/
   $ cd $GOPATH/src/github.com/example-inc/
   $ operator-sdk new memcached-operator --dep-manager dep
   $ cd memcached-operator

2. Add a new Custom Resource Definition (CRD).

   1. Use the CLI to add a new CRD API called Memcached, with APIVersion set to cache.example.com/v1apha1 and Kind set to Memcached:

      $ operator-sdk add api \
          --api-version=cache.example.com/v1alpha1 \
          --kind=Memcached

      This scaffolds the Memcached resource API under pkg/apis/cache/v1alpha1/.

   2. Modify the spec and status of the Memcached Custom Resource (CR) at the pkg/apis/cache/v1alpha1/memcached_types.go file:

      type MemcachedSpec struct {
      	// Size is the size of the memcached deployment
      	Size int32 `json:"size"`
      }
      type MemcachedStatus struct {
      	// Nodes are the names of the memcached pods
      	Nodes []string `json:"nodes"`
      }

   3. After modifying the *_types.go file, always run the following command to update the generated code for that resource type:

      $ operator-sdk generate k8s

3. Add a new Controller.

   1. Add a new Controller to the project to watch and reconcile the Memcached resource:

      $ operator-sdk add controller \
          --api-version=cache.example.com/v1alpha1 \
          --kind=Memcached

      This scaffolds a new Controller implementation under pkg/controller/memcached/.

   2. For this example, replace the generated controller file pkg/controller/memcached/memcached_controller.go with the example implementation.

      The example controller executes the following reconciliation logic for each Memcached CR:

      • Create a Memcached Deployment if it does not exist.
      • Ensure that the Deployment size is the same as specified by the Memcached CR spec.
      • Update the Memcached CR status with the names of the Memcached Pods.

      The next two sub-steps inspect how the Controller watches resources and how the reconcile loop is triggered. You can skip these steps to go directly to building and running the Operator.

   3. Inspect the Controller implementation at the pkg/controller/memcached/memcached_controller.go file to see how the Controller watches resources.

      The first watch is for the Memcached type as the primary resource. For each Add, Update, or Delete event, the reconcile loop is sent a reconcile Request (a <namespace>:<name> key) for that Memcached object:

      err := c.Watch(
        &source.Kind{Type: &cachev1alpha1.Memcached{}}, &handler.EnqueueRequestForObject{})

      The next watch is for Deployments, but the event handler maps each event to a reconcile Request for the owner of the Deployment. In this case, this is the Memcached object for which the Deployment was created. This allows the controller to watch Deployments as a secondary resource:

      err := c.Watch(&source.Kind{Type: &appsv1.Deployment{}}, &handler.EnqueueRequestForOwner{
      		IsController: true,
      		OwnerType:    &cachev1alpha1.Memcached{},
      	})

   4. Every Controller has a Reconciler object with a Reconcile() method that implements the reconcile loop. The reconcile loop is passed the Request argument which is a <namespace>:<name> key used to lookup the primary resource object, Memcached, from the cache:

      func (r *ReconcileMemcached) Reconcile(request reconcile.Request) (reconcile.Result, error) {
        // Lookup the Memcached instance for this reconcile request
        memcached := &cachev1alpha1.Memcached{}
        err := r.client.Get(context.TODO(), request.NamespacedName, memcached)
        ...
      }

      Based on the return value of Reconcile() the reconcile Request may be requeued and the loop may be triggered again:

      // Reconcile successful - don't requeue
      return reconcile.Result{}, nil
      // Reconcile failed due to error - requeue
      return reconcile.Result{}, err
      // Requeue for any reason other than error
      return reconcile.Result{Requeue: true}, nil

4. Build and run the Operator.

   1. Before running the Operator, the CRD must be registered with the Kubernetes API server:

      $ oc create \
          -f deploy/crds/cache_v1alpha1_memcached_crd.yaml

   2. After registering the CRD, there are two options for running the Operator:

      • As a Deployment inside a Kubernetes cluster
      • As Go program outside a cluster

      Choose one of the following methods.

      1. Option A: Running as a Deployment inside the cluster.

         1. Build the memcached-operator image and push it to a registry:

            $ operator-sdk build quay.io/example/memcached-operator:v0.0.1

         2. The Deployment manifest is generated at deploy/operator.yaml. Update the Deployment image as follows since the default is just a placeholder:

            $ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml

         3. Ensure you have an account on Quay.io for the next step, or substitute your preferred container registry. On the registry, create a new public image repository named memcached-operator.

         4. Push the image to the registry:

            $ docker push quay.io/example/memcached-operator:v0.0.1

         5. Setup RBAC and deploy memcached-operator:

            $ oc create -f deploy/role.yaml
            $ oc create -f deploy/role_binding.yaml
            $ oc create -f deploy/service_account.yaml
            $ oc create -f deploy/operator.yaml

         6. Verify that memcached-operator is up and running:

            $ oc get deployment
            NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
            memcached-operator       1         1         1            1           1m

      2. Option B: Running locally outside the cluster.

         This method is preferred during development cycle to deploy and test faster.

         Run the Operator locally with the default Kubernetes configuration file present at $HOME/.kube/config:

         $ operator-sdk up local --namespace=default

         You can use a specific kubeconfig using the flag --kubeconfig=<path/to/kubeconfig>.

5. Verify that the Operator can deploy a Memcached application by creating a Memcached CR.

   1. Create the example Memcached CR that was generated at deploy/crds/cache_v1alpha1_memcached_cr.yaml:

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml
      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 3
      
      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. Ensure that memcached-operator creates the Deployment for the CR:

      $ oc get deployment
      NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator       1         1         1            1           2m
      example-memcached        3         3         3            3           1m

   3. Check the Pods and CR status to confirm the status is updated with the memcached Pod names:

      $ oc get pods
      NAME                                  READY     STATUS    RESTARTS   AGE
      example-memcached-6fd7c98d8-7dqdr     1/1       Running   0          1m
      example-memcached-6fd7c98d8-g5k7v     1/1       Running   0          1m
      example-memcached-6fd7c98d8-m7vn7     1/1       Running   0          1m
      memcached-operator-7cc7cfdf86-vvjqk   1/1       Running   0          2m
      
      $ oc get memcached/example-memcached -o yaml
      apiVersion: cache.example.com/v1alpha1
      kind: Memcached
      metadata:
        clusterName: ""
        creationTimestamp: 2018-03-31T22:51:08Z
        generation: 0
        name: example-memcached
        namespace: default
        resourceVersion: "245453"
        selfLink: /apis/cache.example.com/v1alpha1/namespaces/default/memcacheds/example-memcached
        uid: 0026cc97-3536-11e8-bd83-0800274106a1
      spec:
        size: 3
      status:
        nodes:
        - example-memcached-6fd7c98d8-7dqdr
        - example-memcached-6fd7c98d8-g5k7v
        - example-memcached-6fd7c98d8-m7vn7

6. Verify that the Operator can manage a deployed Memcached application by updating the size of the deployment.

   1. Change the spec.size field in the memcached CR from 3 to 4:

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml
      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 4

   2. Apply the change:

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   3. Confirm that the Operator changes the Deployment size:

      $ oc get deployment
      NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      example-memcached    4         4         4            4           5m

7. Clean up the resources:

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_cr.yaml
   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_crd.yaml
   $ oc delete -f deploy/operator.yaml
   $ oc delete -f deploy/role.yaml
   $ oc delete -f deploy/role_binding.yaml
   $ oc delete -f deploy/service_account.yaml