Cluster management in IBM Cloud.

As you can see from the list here,

IBM cloud container service takes care of

many cluster management tasks that you would otherwise have to handle yourself,

such as deploying Kubernetes components, managing updates,

health monitoring, configuring default networking and security settings, and so on.

As an IBM customer,

you are responsible for the tasks listed here,

which include deploying and managing your Kubernetes pods,

services, and so on.

It is up to you to configure your clusters for high availability and reliability,

add or remove worker nodes,

configure networking and security as needed for your application,

apply updates when they are available, and make backups.

Some of these topics are covered in detail elsewhere in this course.

And in the reading that follows this lecture,

I provide links to the IBM cloud documentation that covers these topics in more detail.

There are a number of ways that you can manage what actions

a user can perform on a cluster in IBM cloud.

IBM cloud container service access policies determine the actions that you can perform on

a cluster such as creating or removing clusters and adding or removing worker nodes.

Infrastructure access policies control actions that are

requested from the IBM cloud user interface or the command line interface.

A resource group is a way to organize IBM cloud services into

groupings so that you can quickly assign

users access to more than one resource at a time.

Every user of IBM cloud is assigned a Cloud Foundry user role.

This role determines the actions that you can perform on

the IBM cloud account such as inviting other users or viewing the quota usage.

Every user who is assigned

an IBM cloud container service access policy

is automatically assigned a Kubernetes RBAC role.

In Kubernetes, RBAC roles determine the actions that you can

perform an Kubernetes resources inside the cluster.

RBAC roles are set up for the default namespace.

The cluster administrator can add RBAC roles for other namespaces in the cluster.

The table here lists the access policies and

permissions that you can grant to users in your IBM cloud account.

The administrator role is essentially

the super user and inherits permissions from all the other roles.

The operator and editor roles have separate permissions.

So, if you want a user to add worker nodes and bind services,

then you must assign the user both the operator and editor roles.

The viewer, of course,

has the weakest permissions here.

To add users to an IBM cloud account, from the menu bar,

click manage, security, identity and access,

and then click users.

From here, you can click invite users and then specify the email address of the user.

Under access, expand services.

Here, you can assign roles for a specific resource,

like IBM cloud container service,

or for a group of resources in your account.

You can specify all regions or a specific region,

and you can choose a specific service instance, for example,

mycluster is selected here,

or you can select all service instances.

And then, select the roles that you want to assign to the user.

You can follow a similar procedure to assign

an infrastructure role or Cloud Foundry role.

Use encrypted Kubernetes secrets to store

IBM cloud service details and credentials

and allow secure communication between the service and the cluster.

As the cluster user,

you can access the secret by mounting it as a volume to a pod.

Kubernetes secrets are a secure way to store

confidential information such as usernames, passwords, or keys.

Rather than exposing confidential information via

environment variables or directly in the docker file,

secrets must be mounted as a secret volume to

a pod in order to be accessible by a running container in a pod.

You can list the secrets in your cluster namespace by

using the kubectl get secrets command shown here.

And then, create a deployment that defines the secret volume and details.

When you mount a secret volume to your pod,

a file named binding is stored in the volume mount directory that

includes all information and credentials that you need to access the IBM cloud service.

To work with your IBM cloud service,

make sure your app is configured to find the service secret file in the mount directory,

parse the JSON content,

and determine the service details.

The IBM cloud documentation has more information about working with IBM cloud services.

With a standard cluster,

you can create a persistent volume claim,

or PVC, to provision NFS file storage for your cluster.

Then, mount this claim to a deployment to ensure that data

is available even if the pods crash or shut down.

The NFS file storage that backs the persistent volume is

clustered by IBM in order to provide high availability for your data.

IBM cloud container service provides

eight predefined storage classes so that

the cluster admin does not have to create any storage classes.

You can view the storage classes by running kubectl get storage classes.

Decide if you want to save your data in the NFS file share after you delete the PVC.

If you want to keep your data,

then choose a retain storage class.

If you want the data in your file share to be deleted when you delete the PVC,

choose the storage class without routine.

Review the IOPS of a storage class and the available storage sizes.

You can find more information about these options in the IBM cloud documentation.

Then, create a persistent volume claim configuration file to define the PVC information.

The example shown here is for the bronze,

silver, or gold classes.

To create the PVC,

run the kubectl apply -f command against the filename and then verify that

the PVC was created by running kubectl described PVC with the PVC name as an argument.

To mount the PVC to a deployment,

reference the PVC in the deployment configuration file as shown here.

Run the kubectl apply -f command against the deployment file,

and then run kubectl describe deployment with

the deployment name as an argument to the command to verify the results.

The output should indicate the mount point in the volume

mount field and the volume in the volumes field.

Non-write users do not have write permission on

the volume mount path for NFS backed storage.

To grant write permission,

you must edit the docker file of the image to

create a directory on the mount path with the correct permission.

For more information about this task,

see the IBM cloud documentation.

Cluster management in IBM Cloud

IBM Cloud: Deploying Microservices with Kubernetes

Conoce a los instructores