+

Search Tips   |   Advanced Search

Command Reference: OpenShift on IBM Cloud

Refer to these commands to create and manage both community Kubernetes or OpenShift clusters in Red Hat OpenShifton IBM Cloud.

In the terminal, we are notified when updates to the ibmcloud CLI and plug-ins are available. Be sure to keep your CLI up-to-date so that we can use all available commands and flags.

Looking for ibmcloud cr commands? See the IBM Cloud Container Registry CLI reference. Looking for kubectl commands? See the Kubernetes documentation.


Comparison of Classic and VPC commands

With the release of the IBM Cloud Kubernetes Service version 2 API, the IBM Cloud CLI kubernetes-service plug-in supports both classic and VPC infrastructure providers. Some ibmcloud oc commands support only one type of infrastructure, whereas other commands include additional names or options as described in the following table.

Area Classic CLI commands VPC CLI commands
Doc icons
Provider-specific: We can perform similar operations in both infrastructure providers, but we must specify the infrastructure provider in the command name.

If you do not specify the provider, the default is classic. For example, zone add classic is an alias for the previous zone-add classic command.		 v1 API v2 API
Provider-exclusive: We can use these commands only in the particular infrastructure provider. v1 API v2 API
VPC provider flags: We can specify a --provider flag for these commands to return results that are specific to the infrastructure provider. Optional. v1 API Required. v2 API
Neutral: You do not need to specify an infrastructure provider for the remaining commands. The commands use and return the v1 API responses. The commands use and return the v1 API responses.



cluster commands

Create, view, and modify clusters and cluster settings, such as add-on, subnet, and master settings.


ibmcloud oc cluster addon disable

Disable a managed add-on in an existing cluster. This command must be combined with one of the following subcommands for the managed add-on that we want to disable.


disable debug-tool

Disable the add-on for the IBM Cloud Kubernetes Service Diagnostics and Debug Tool.

    ibmcloud oc cluster addon disable debug-tool --cluster CLUSTER [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -f
    Optional: Force the command to run with no user prompts.


ibmcloud oc cluster addon disable kube-terminal

Disable the Kubernetes Terminal add-on. To use the Kubernetes Terminal in the IBM Cloud Kubernetes Service cluster console, we must re-enable the add-on first.

    ibmcloud oc cluster addon disable kube-terminal --cluster CLUSTER [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -f
    Optional: Force the command to run with no user prompts.


ibmcloud oc cluster addon disable static-route

Disable the static route add-on.

    ibmcloud oc cluster addon disable static-route --cluster CLUSTER

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service




ibmcloud oc cluster addon enable

Enable a managed add-on in an existing cluster. This command must be combined with one of the following subcommands for the managed add-on that we want to enable.


ibmcloud oc cluster addon enable debug-tool

Enable the add-on for the IBM Cloud Kubernetes Service Diagnostics and Debug Tool in a cluster.

    ibmcloud oc cluster addon enable debug-tool --cluster CLUSTER [--version VERSION]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --version VERSION
    Optional: Specify the version of the add-on to install. If no version is specified, the default version is installed.

Example:

    ibmcloud oc cluster addon enable debug-tool --cluster my_cluster


ibmcloud oc cluster addon enable kube-terminal

Enable the Kubernetes Terminal add-on to use the Kubernetes Terminal in the IBM Cloud Kubernetes Service cluster console.

    ibmcloud oc cluster addon enable kube-terminal --cluster CLUSTER [--version VERSION]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --version VERSION
    Optional: Specify the version of the add-on to install. If no version is specified, the default version is installed.


ibmcloud oc cluster addon enable static-route

Enable the static route add-on.

    ibmcloud oc cluster addon enable static-route --cluster CLUSTER [--version VERSION]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --cluster <em>CLUSTER</em>
    Required: The name or ID of the cluster.

    --version VERSION
    Optional: Specify the version of the add-on to install. If no version is specified, the default version is installed.



ibmcloud oc cluster addon ls

List any managed add-ons that are enabled in a cluster.

    ibmcloud oc cluster addon ls --cluster CLUSTER

Supported infrastructure provider:

  • Classic
  • VPC Generation 1 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.



ibmcloud oc cluster ca create

Create a new certificate authority (CA) for the cluster. After the CA is created and new CA certificates are issued for components in the cluster, the API server of the cluster is automatically refreshed.

After running this command and before running the ibmcloud oc cluster ca rotate command, follow the steps in Rotating CA certificates in the cluster to ensure that any tooling that uses certificates that are signed by the old CA is updated to use the new certificates and to update your worker nodes.

    ibmcloud oc cluster ca create --cluster CLUSTER [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster ca create --cluster my_cluster



ibmcloud oc cluster ca rotate

Rotate the certificate authority (CA) certificates of a cluster. Rotating invalidates certificates signed by the cluster's previous CA and issues certificates signed by the cluster's new CA to worker nodes.

Before you run this command, follow the steps in Rotating CA certificates in the cluster to ensure that any tooling that uses the old CA certificates is updated to use the new certificates and to update your worker nodes.

    ibmcloud oc cluster ca rotate --cluster CLUSTER [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster ca rotate --cluster my_cluster



ibmcloud oc cluster ca status

After you run ibmcloud oc cluster ca rotate, view the rotation status of certificate authority (CA) certificates for a cluster.

    ibmcloud oc cluster ca status --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster ca status --cluster my_cluster



ibmcloud oc cluster config

After logging in to IBM Cloud, download the Kubernetes configuration data and certificates as a kubeconfig file to the local machine so that we can connect to the cluster and run oc commands.

The kubeconfig file is merged to the existing kubeconfig file in ~/.kube/config (<user_profile>/.kube/config in Windows), or to the last file that is set by the KUBECONFIG environment variable in your terminal session. After you run ibmcloud oc cluster config, we can interact with the cluster immediately, and quickly change the context to other clusters in the Kubernetes context.

    ibmcloud oc cluster config --cluster CLUSTER [--admin] [--network] [--skip-rbac] [-q] [--yaml]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer or Reader IBM Cloud IAM service role for the cluster in IBM Cloud Kubernetes Service. Further, if we have only a platform role or only a service role, additional constraints apply.

  • Platform: If we have only a platform role, we can perform this command, but we need a service role or a custom RBAC policy to perform Kubernetes actions in the cluster.
  • Service: If we have only a service role, we can perform this command. However, the cluster admin must give you the cluster name, ID, and master URL because we cannot run the ibmcloud oc cluster ls command or open the IBM Cloud Kubernetes Service console to view clusters. After you receive the cluster name and ID, we can open the OpenShift web console by opening your browser to <master_URL>/console.

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --admin
    Optional: Download the TLS certificates and permission files for the Super User role. We can use the certs to automate tasks in a cluster without having to reauthenticate. The files are downloaded to <user_home_directory>/.bluemix/plugins/kubernetes-service/clusters/<cluster_name>-admin.

    --network
    Optional: Download the Calico configuration file, TLS certificates, and permission files that are required to run calicoctl commands in the cluster. Note: This option cannot be used with the --yaml option.

    --skip-rbac
    Skip adding user Kubernetes RBAC roles based on the IBM Cloud IAM service access roles to the cluster configuration. Include this option only if you manage your own Kubernetes RBAC roles. If you use IBM Cloud IAM service access roles to manage all your RBAC users, do not include this option.

    -q
    Optional: Do not show the message of the day or update reminders.

    --yaml
    Optional: Prints the command output in YAML format.

Example:

    ibmcloud oc cluster config --cluster my_cluster



ibmcloud oc cluster create classic

Create a cluster with worker nodes on classic infrastructure. For free clusters, you specify the cluster name; everything else is set to a default value. A free cluster is automatically deleted after 30 days. We can have one free cluster at a time. To take advantage of the full capabilities of Kubernetes, create a standard cluster.

    ibmcloud oc cluster create classic [--hardware HARDWARE] --zone ZONE --flavor FLAVOR --name NAME [--version MAJOR.MINOR.PATCH] [--no-subnet] [--private-vlan PRIVATE_VLAN] [--public-vlan PUBLIC_VLAN] [--private-service-endpoint] [--public-service-endpoint] [--workers WORKER] [--disable-disk-encrypt] [--pod-subnet SUBNET] [--service-subnet SUBNET] [--skip-advance-permissions-check] [--entitlement cloud_pak][-q]

Supported infrastructure provider: Classic. To create a VPC Generation 2 compute cluster, use the ibmcloud oc cluster create vpc-gen2 command instead.

Minimum required permissions:

  • Administrator platform role for IBM Cloud Kubernetes Service at the account level
  • Administrator platform role for IBM Cloud Container Registry at the account level
  • Super User role for IBM Cloud infrastructure

Command options

    --hardware HARDWARE
    The level of hardware isolation for the worker node. Use dedicated so that available physical resources are dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. This value is optional for VM standard clusters and is not available for free clusters. For bare metal flavors, specify dedicated.

    --zone ZONE
    The zone where we want to create the cluster. This value is required for standard clusters. Free clusters can be created in the region that you target with the ibmcloud oc init command, but we cannot specify the zone.

    Review available zones. To span the cluster across zones, we must create the cluster in a multizone-capable zone.

    When you select a zone that is located outside your country, keep in mind that we might require legal authorization before data can be physically stored in a foreign country.

    --flavor FLAVOR
    Choose a flavor, or machine type, for the worker nodes. We can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual flavors vary by the zone in which we deploy the cluster. For more information, see the documentation for the ibmcloud oc flavors (machine-types) command. This value is required for standard clusters and is not available for free clusters.

    --name NAME
    Required: The name for the cluster. The name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer. Use a name that is unique across regions. The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

    --version MAJOR.MINOR.PATCH
    Optional: The Kubernetes version for the cluster master node. When the version is not specified, the cluster is created with the default of supported Kubernetes versions. To see available versions, run ibmcloud oc versions.

    --no-subnet
    By default, a public and a private portable subnet are created on the VLAN associated with the cluster. Include the --no-subnet flag to avoid creating subnets with the cluster. We can create or add subnets to a cluster later.

    --private-vlan PRIVATE_VLAN
    • This parameter is not available for free clusters.
    • If this standard cluster is the first standard cluster that you create in this zone, do not include this flag. A private VLAN is created for you when the cluster is created.
    • If you created a standard cluster before in this zone or created a private VLAN in IBM Cloud infrastructure before, we must specify that private VLAN. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

    To find out whether you already have a private VLAN for a specific zone or to find the name of an existing private VLAN, run ibmcloud oc vlan ls --zone <zone>.

    --public-vlan PUBLIC_VLAN
    • This parameter is not available for free clusters.
    • If this standard cluster is the first standard cluster that you create in this zone, do not use this flag. A public VLAN is created for you when the cluster is created.
    • If you created a standard cluster before in this zone or created a public VLAN in IBM Cloud infrastructure before, specify that public VLAN. To connect your worker nodes to a private VLAN only, do not specify this option. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

    To find out whether you already have a public VLAN for a specific zone or to find the name of an existing public VLAN, run ibmcloud oc vlan ls --zone <zone>.

    --private-service-endpoint
    OpenShift 3.11 clusters only in accounts that are enabled with VRF and service endpoints: Enable the private service endpoint so that your Kubernetes master and the worker nodes communicate over the private VLAN. After you enable a private service endpoint, we cannot later disable it.

    After creating the cluster, we can get the endpoint by running ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

    --public-service-endpoint
    Enable the public service endpoint so that your Kubernetes master can be accessed over the public network, for example to run oc commands from your terminal. For 3.11 clusters only, i we have an account that is enabled with VRF and service endpoints and also include the --private-service-endpoint flag, master-worker node communication goes over the private and the public network.

    After creating the cluster, we can get the endpoint by running ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

    --workers WORKER
    Optional: The number of worker nodes that we want to deploy in the cluster. If you do not specify this option, a cluster with the minimum value of 2 is created. For more information, see What is the smallest size cluster that I can make?.

    If you create a cluster with only one worker node per zone, we might experience issues with Ingress. For high availability, create a cluster with at least two workers per zone.

    Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing the cluster.

    --disable-disk-encrypt
    Worker nodes feature AES 256-bit disk encryption by default; learn more. To disable encryption, include this option.

    --pod-subnet SUBNET
    All pods that are deployed to a worker node are assigned a private IP address in the 172.30.0.0/16 range by default. If we plan to connect the cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, we can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for the pods.

    When you choose a subnet size, consider the size of the cluster that we plan to create and the number of worker nodes that we might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.

    The subnet that you choose must be within one of the following ranges:

    • 172.17.0.0 - 172.17.255.255
    • 172.21.0.0 - 172.31.255.255
    • 192.168.0.0 - 192.168.254.255
    • 198.18.0.0 - 198.19.255.255
    Note that the pod and service subnets cannot overlap. The service subnet is in the 172.21.0.0/16 range by default.

    --service-subnet SUBNET
    All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If we plan to connect the cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, we can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for the services.

    The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges:

    • 172.17.0.0 - 172.17.255.255
    • 172.21.0.0 - 172.31.255.255
    • 192.168.0.0 - 192.168.254.255
    • 198.18.0.0 - 198.19.255.255
    Note that the pod and service subnets cannot overlap. The pod subnet is in the 172.30.0.0/16 range by default.

    --skip-advance-permissions-check
    Optional: Skip the check for infrastructure permissions before creating the cluster. Note that if you do not have the correct infrastructure permissions, the cluster creation might only partially succeed, such as the master provisioning but the worker nodes unable to provision. We might skip the permissions check if we want to continue an otherwise blocked operation, such as when you use multiple infrastructure accounts and can handle the infrastructure resources separately from the master, if needed later.

    --entitlement cloud_pak
    Include this flag only if you use this cluster with an IBM Cloud Pak™ that has an OpenShift entitlement. When you specify the number of workers (--workers) and flavor (--flavor), make sure to specify only the number and size of worker nodes that we are entitled to use in IBM Passport Advantage{: external}. After the cluster is created, we are not charged the OpenShift license fee for the entitled worker nodes in the default worker pool.

    Do not exceed your entitlement. Keep in mind that the OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what we are entitled to use. For example, we might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and we cannot use the same entitlement for other worker pools, cloud providers, or environments.

    -q
    Optional: Do not show the message of the day or update reminders.

Examples:

Create a free cluster: Specify the cluster name only; everything else is set to a default value. A free cluster is automatically deleted after 30 days. We can have one free cluster at a time. To take advantage of the full capabilities of Kubernetes, create a standard cluster.

    ibmcloud oc cluster create classic --name my_cluster

Create your first standard cluster: The first standard cluster that is created in a zone also creates a private VLAN. Therefore, do not include the --public-vlan flag.

    ibmcloud oc cluster create classic --zone dal10 --private-vlan my_private_VLAN_ID --flavor b3c.4x16 --name my_cluster --hardware shared --workers 2

Create subsequent standard clusters: If you already created a standard cluster in this zone or created a public VLAN in IBM Cloud infrastructure before, specify that public VLAN with the --public-vlan flag. To find out whether you already have a public VLAN for a specific zone or to find the name of an existing public VLAN, run ibmcloud oc vlan ls --zone <zone>.

    ibmcloud oc cluster create classic --zone dal10 --public-vlan my_public_VLAN_ID --private-vlan my_private_VLAN_ID --flavor b3c.4x16 --name my_cluster --hardware shared --workers 2



Beta: ibmcloud oc cluster create satellite

Create an IBM Cloud Satellite cluster on your own infrastructure that you add to a Satellite location as hosts. The hosts are used as worker nodes in your Satellite cluster.

IBM Cloud Satellite is available as a closed beta and is subject to change. To register for the beta, see the product details page.

Before beginning, create a Satellite and assign at least three hosts to the location for control plane operations. After creating a Satellite cluster, assign hosts for the worker nodes. For more information, see Creating OpenShift clusters in Satellite.

    ibmcloud oc cluster create satellite --location LOCATION --name NAME --version VERSION [-q]


Minimum required permissions: IBM Cloud IAM Administrator platform role for Satellite.

Command options:

    --location LOCATION
    Required. Enter the ID or name of the location where we want to create the cluster. To retrieve the location ID or name, run ibmcloud sat location ls.

    --name NAME
    Required. Enter a name for the cluster. The name must start with a letter, can contain letters, numbers, and hyphen (-), and must be 35 characters or fewer.

    --version VERSION
    Required. Enter the Red Hat OpenShift on IBM Cloud version that we want to run in the cluster. For a list of supported versions, run ibmcloud oc versions.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud sat cluster create satellite --name mysatcluster --location mylocation --version 4.4_openshift



ibmcloud oc cluster create vpc-gen2

Create a Virtual Private Cloud (VPC) cluster with worker nodes on Generation 2 infrastructure. When you log in to your IBM Cloud account, target the IBM Cloud region and resource group where we want to create your VPC cluster. For supported regions, see Creating a VPC in a different region. The cluster's resource group can differ from the VPC resource group.

Free clusters are not available in VPC.

    ibmcloud oc cluster create vpc-gen2 --name NAME --zone ZONE --vpc-id VPC_ID --subnet-id VPC_SUBNET_ID --flavor WORKER_FLAVOR [--version 4.4_openshift] --cos-instance COS_ID [--workers NUMBER_WORKERS_PER_ZONE] [--disable-public-service-endpoint] [--pod-subnet SUBNET] [--service-subnet SUBNET] [--entitlement cloud_pak] [--skip-advance-permissions-check] [-q]

Supported infrastructure provider: VPC Generation 2 compute

Minimum required permissions:

Command options

    --name NAME
    Required: The name for the cluster. The name must start with a letter, can contain letters, numbers, periods (.), and hyphen (-), and must be 35 characters or fewer. Use a name that is unique across regions. The cluster name and the region in which the cluster is deployed form the fully qualified domain name for the Ingress subdomain. To ensure that the Ingress subdomain is unique within a region, the cluster name might be truncated and appended with a random value within the Ingress domain name.

    --zone ZONE
    Required: Select a zone to deploy the initial cluster worker pool in. If you create the cluster in a multizone metro, we can add a zone to the worker pool later. To list available VPC zones, run ibmcloud oc zone ls --provider vpc-gen2.

    When you select a zone that is located outside your country, keep in mind that we might require legal authorization before data can be physically stored in a foreign country.

    --vpc-id VPC_ID
    Required: The ID of the VPC in which to create the cluster and worker nodes. To list available IDs, run ibmcloud oc vpcs.

    --subnet-id VPC_SUBNET_ID
    Required: The VPC subnet to assign the cluster. To list available VPC subnets, run ibmcloud oc subnets --provider vpc-gen2.

    --version 4.4_openshift
    VPC Gen 2 clusters are supported for OpenShift version 4 only.

    --flavor FLAVOR
    Choose a flavor for the worker nodes. We can deploy your worker nodes as virtual machines on shared or dedicated hardware. To see flavors that are available in a zone, run ibmcloud oc flavors --zone <vpc_zone> --provider vpc-gen2.

    --cos-instance <cos_ID>
    Include the CRN ID of a standard IBM Cloud Object Storage instance to back up the internal registry of the cluster. To list the CRN of existing instances, run ibmcloud resource service-instances --long and find the ID of our object storage instance. To create a standard object storage instance, run ibmcloud resource service-instance-create <name> cloud-object-storage standard global and note its ID.

    --workers NUMBER_WORKERS_PER_ZONE
    Optional: The number of worker nodes that we want to deploy in the cluster. If you do not specify this option, a cluster with the minimum value of 2 is created. For more information, see What is the smallest size cluster that I can make?.

    Every worker node is assigned a unique worker node ID and domain name that must not be manually changed after the cluster is created. Changing the ID or domain name prevents the Kubernetes master from managing the cluster.

    --disable-public-service-endpoint
    To ensure that worker nodes and authorized cluster users communicate with the master through the private service endpoint only, include this flag to create the cluster without the public service endpoint.

    If you include this flag, the cluster is created with routers and Ingress controllers that expose our apps on the private network only by default. If you later want to expose apps to a public network, we must manually create public routers and Ingress controllers.

    --pod-subnet SUBNET
    In the first cluster that you create in a Gen 2 VPC, the default pod subnet is 172.17.0.0/18. In the second cluster that you create in that VPC, the default pod subnet is 172.17.64.0/18. In each subsequent cluster, the pod subnet range is the next available, non-overlapping /18 subnet. If we plan to connect the cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, we can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for the pods.

    When you choose a subnet size, consider the size of the cluster that we plan to create and the number of worker nodes that we might add in the future. The subnet must have a CIDR of at least /23, which provides enough pod IPs for a maximum of four worker nodes in a cluster. For larger clusters, use /22 to have enough pod IP addresses for eight worker nodes, /21 to have enough pod IP addresses for 16 worker nodes, and so on.

    The subnet that you choose must be within one of the following ranges:

    • 172.17.0.0 - 172.17.255.255
    • 172.21.0.0 - 172.31.255.255
    • 192.168.0.0 - 192.168.254.255
    • 198.18.0.0 - 198.19.255.255
    Note that the pod and service subnets cannot overlap. If you use custom-range subnets for the worker nodes, we must ensure that your worker node subnets do not overlap with the cluster's pod subnet.

    --service-subnet SUBNET
    All services that are deployed to the cluster are assigned a private IP address in the 172.21.0.0/16 range by default. If we plan to connect the cluster to on-premises networks through IBM Cloud Direct Link or a VPN service, we can avoid subnet conflicts by specifying a custom subnet CIDR that provides the private IP addresses for the services.

    The subnet must be specified in CIDR format with a size of at least /24, which allows a maximum of 255 services in the cluster, or larger. The subnet that you choose must be within one of the following ranges:

    • 172.17.0.0 - 172.17.255.255
    • 172.21.0.0 - 172.31.255.255
    • 192.168.0.0 - 192.168.254.255
    • 198.18.0.0 - 198.19.255.255
    Note that the pod and service subnets cannot overlap.

    --entitlement cloud_pak
    Include this flag only if you use this cluster with an IBM Cloud Pak™ that has an OpenShift entitlement. When you specify the number of workers (--workers) and flavor (--flavor), make sure to specify only the number and size of worker nodes that we are entitled to use in IBM Passport Advantage{: external}. After the cluster is created, we are not charged the OpenShift license fee for the entitled worker nodes in the default worker pool.

    Do not exceed your entitlement. Keep in mind that the OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what we are entitled to use. For example, we might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and we cannot use the same entitlement for other worker pools, cloud providers, or environments.

    --skip-advance-permissions-check
    Optional: Skip the check for infrastructure permissions before creating the cluster. Note that if you do not have the correct infrastructure permissions, the cluster creation might only partially succeed, such as the master provisioning but the worker nodes unable to provision. We might skip the permissions check if we want to continue an otherwise blocked operation, such as when you use multiple infrastructure accounts and can handle the infrastructure resources separately from the master, if needed later.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster create vpc-gen2 --name mycluster --version 4.4_openshift --zone us-south-1 --vpc-id a0123456-78b9-0c1d-23d4-567890123ef4 --subnet-id 1ab23c45-6789-0123-456d-789ef01gh234 --flavor bx2.4x16 --workers 3



ibmcloud oc cluster get

View the details of a cluster.

    ibmcloud oc cluster get --cluster CLUSTER [--show-resources] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --show-resources
    Show more cluster resources such as add-ons, VLANs, subnets, and storage.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster get --cluster my_cluster --show-resources



ibmcloud oc cluster ls

List all clusters in your IBM Cloud account.

Clusters in all locations are returned. To filter clusters by a specific location, include the --location flag. For example, if you filter clusters for the dal metro, multizone clusters in that metro and single-zone clusters in data centers (zones) within that metro are returned. If you filter clusters for the dal10 data center (zone), multizone clusters that have a worker node in that zone and single-zone clusters in that zone are returned. We can pass one location or a comma-separated list of locations.

    ibmcloud oc cluster ls [--provider (classic | vpc-gen2)] [--location LOCATION] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --provider (classic | vpc-gen2)
    Optional: Filter output based on infrastructure provider type.

    -l, --location LOCATION
    Filter output by a specific location. To see supported locations, run ibmcloud oc locations. To specify multiple locations, use one flag for each location, such as -l dal -l seo.

    --output json
    Optional: Prints the command output in JSON format. Note: If you do not include the --provider flag, only classic clusters are returned.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster ls -l ams03 -l wdc -l ap



ibmcloud oc cluster master private-service-endpoint enable

Enable the private service endpoint to make the cluster master privately accessible.

To run this command:

  1. Enable VRF in your IBM Cloud infrastructure account. To check whether a VRF is already enabled, use the ibmcloud account show command.
  2. Enable your IBM Cloud account to use service endpoints.
  3. Run ibmcloud oc cluster master private-service-endpoint enable --cluster <cluster_name>.
  4. Follow the prompt in the CLI to refresh the Kubernetes master API server.
  5. Reload all the worker nodes in the cluster to pick up the private endpoint configuration.

    ibmcloud oc cluster master private-service-endpoint enable --cluster CLUSTER [-q]

Supported infrastructure provider: Classic. The private service endpoint is permanently enabled by default for VPC clusters.

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.

    -y
    Optional: Refresh the cluster master and reload worker nodes with no user prompts.

Example:

    ibmcloud oc cluster master private-service-endpoint enable --cluster my_cluster



ibmcloud oc cluster master public-service-endpoint enable

Enable the public service endpoint to make the cluster master publicly accessible.

After running this command, we must refresh the API server to use the service endpoint by following the prompt in the CLI.

    ibmcloud oc cluster master public-service-endpoint enable --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.

    -y
    Optional: Refresh the cluster master with no user prompts.

Example:

    ibmcloud oc cluster master public-service-endpoint enable --cluster my_cluster



ibmcloud oc cluster master refresh

Apply configuration changes for the Kubernetes master that are requested with the ibmcloud oc cluster master commands. The highly available Kubernetes master components are restarted in a rolling restart. Your worker nodes, apps, and resources are not modified and continue to run.

The apiserver-refresh and cluster-refresh aliases for this command are deprecated.

    ibmcloud oc cluster master refresh --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc cluster master update

Update the Kubernetes master to the default API version. During the update, we cannot access or change the cluster. Worker nodes, apps, and resources that were deployed by the user are not modified and continue to run.

We might need to change your YAML files for future deployments. Review this release note for details.

The cluster-update alias for this command is deprecated.

    ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --version MAJOR.MINOR.PATCH
    Optional: The Kubernetes version of the cluster. If you do not specify a version, the Kubernetes master is updated to the default API version. To see available versions, run ibmcloud oc versions.

    --force-update
    Optional: Attempt the update even if the change is greater than two minor versions from the worker node version.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster master update --cluster my_cluster



ibmcloud oc cluster pull-secret apply

Make an IBM Cloud IAM service ID for the cluster, create a policy for the service ID that assigns the Reader service access role in IBM Cloud Container Registry, and then create an API key for the service ID. The API key is then stored in a Kubernetes image pull secret so that we can pull images from your IBM Cloud Container Registry namespaces for containers that are in the default OpenShift project. This process happens automatically when you create a cluster. If you got an error during the cluster creation process or have an existing cluster, we can use this command to apply the process again.

This API key method replaces the previous method of authorizing a cluster to access IBM Cloud Container Registry by automatically creating a token and storing the token in an image pull secret. Now, by using IAM API keys to access IBM Cloud Container Registry, we can customize IAM policies for the service ID to restrict access to your namespaces or specific images. For example, we can change the service ID policies in the cluster's image pull secret to pull images from only a certain registry region or namespace. Before we can customize IAM policies, we must enable IBM Cloud IAM policies for IBM Cloud Container Registry.

For more information, see Understand how the cluster is authorized to pull images from IBM Cloud Container Registry.

When you run this command, the creation of IAM credentials and image pull secrets is initiated and can take some time to complete. We cannot deploy containers that pull an image from the IBM Cloud Container Registry icr.io domains until the image pull secrets are created. To check the image pull secrets, run oc get secrets | grep icr-io.

If you added IAM policies to an existing service ID, such as to restrict access to a regional registry, the service ID, IAM policies, and API key for the image pull secret are reset by this command.

    ibmcloud oc cluster pull-secret apply --cluster CLUSTER

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions:

  • Operator or Administrator platform role for the cluster in IBM Cloud Kubernetes Service
  • Administrator platform role in IBM Cloud Container Registry across all regions and resource groups. The policy cannot be scoped to a particular region or resource group.

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.



ibmcloud oc cluster rm

Delete a cluster. All worker nodes, apps, and containers are permanently deleted. This action cannot be undone.

    ibmcloud oc cluster rm --cluster CLUSTER [--force-delete-storage] [--skip-advance-permissions-check] [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --force-delete-storage
    Optional: Deletes the cluster and any persistent storage that the cluster uses. Attention: If you include this flag, the data that is stored in the cluster or its associated storage instances cannot be recovered.

    --skip-advance-permissions-check
    Optional: Skip the check for infrastructure permissions before deleting the cluster. Note that if you do not have the correct infrastructure permissions, the cluster deletion might only partially succeed, such as the IBM-managed master being removed but the worker nodes unable to be removed from your infrastructure account. We might skip the permissions check if we want to continue an otherwise blocked operation, such as when you use multiple infrastructure accounts and can handle the infrastructure resources separately from the master, if needed later.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster rm --cluster my_cluster



ibmcloud oc cluster service bind

Add an IBM Cloud service to a cluster by binding the service instance to a OpenShift project. This command creates service credentials of an IBM Cloud service and stores these credentials in a Kubernetes secret in the cluster.

To view available IBM Cloud services from the IBM Cloud catalog, run ibmcloud service offerings. Note: We can add only IBM Cloud services that support service keys. For more information about service binding and what services we can add to the cluster, see Adding services by using IBM Cloud service binding.

    ibmcloud oc cluster service bind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE [--key SERVICE_INSTANCE_KEY] [--role IAM_SERVICE_ROLE] --service SERVICE_INSTANCE [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service and Developer Cloud Foundry role

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -n, --namespace KUBERNETES_NAMESPACE
    Required: The name of the OpenShift project where we want to create the Kubernetes secret for the service credentials.

    --key SERVICE_INSTANCE_KEY
    Optional: The name or GUID of an existing service key. When you use the service-binding command, new service credentials are automatically created for the service instance and assigned the IAM Writer service access role for IAM-enabled services. To use an existing service key that you created earlier, use this option. If you define a service key, we cannot set the --role option at the same time because your service keys are already created with a specific IAM service access role.

    --role IAM_SERVICE_ROLE
    The IBM Cloud IAM role that we want the service key to have. This value is optional and can be used for IAM-enabled services only. If you do not set this option, your service credentials are automatically created and assigned the IAM Writer service access role. To use existing service keys by specifying the --key option, do not include this option.

    To list available roles for the service, run ibmcloud iam roles --service <service_name>. The service name is the name of the service in the catalog, which we can get by running ibmcloud catalog search.

    --service SERVICE_INSTANCE
    Required: The name of the IBM Cloud service instance that we want to bind. To find the name, run ibmcloud service list for Cloud Foundry services, and ibmcloud resource service-instances for IAM-enabled services.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster service bind --cluster my_cluster --namespace my_namespace --service my_service_instance



ibmcloud oc cluster service ls

List the services that are bound to one or all of the OpenShift project in a cluster. If no options are specified, the services for the default project are displayed.

    ibmcloud oc cluster service ls --cluster CLUSTER [--namespace KUBERNETES_NAMESPACE] [--all-namespaces] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -n, --namespace KUBERNETES_NAMESPACE
    Optional: Include the services that are bound to a specific project in a cluster.

    --all-namespaces
    Optional: Include the services that are bound to all of the projects in a cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster service ls --cluster my_cluster --namespace my_namespace



ibmcloud oc cluster service unbind

Remove an IBM Cloud service from a cluster by unbinding it from a OpenShift project.

When you remove an IBM Cloud service, the service credentials are removed from the cluster. If a pod is still using the service, it fails because the service credentials cannot be found.

    ibmcloud oc cluster service unbind --cluster CLUSTER --namespace KUBERNETES_NAMESPACE --service SERVICE_INSTANCE [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service and Developer Cloud Foundry role

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -n, --namespace KUBERNETES_NAMESPACE
    Required: The name of the OpenShift project.

    --service SERVICE_INSTANCE
    Required: The name of the IBM Cloud service instance that we want to remove. To find the name of the service instance, run ibmcloud oc cluster service ls --cluster <cluster_name_or_ID>.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster service unbind --cluster my_cluster --namespace my_namespace --service 8567221



ibmcloud oc cluster subnet add

Make an existing portable public or private classic subnet in your IBM Cloud infrastructure account available to a cluster or reuse subnets from a deleted cluster instead of using the automatically provisioned subnets.

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of IBM Cloud Kubernetes Service at the same time.

To enable communication between workers that are on different subnets on the same VLAN in non-VRF accounts, we must enable routing between subnets on the same VLAN.

    ibmcloud oc cluster subnet add --cluster CLUSTER --subnet-id SUBNET [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --subnet-id SUBNET
    Required: The ID of the subnet.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster subnet add --cluster my_cluster --subnet-id 1643389



ibmcloud oc cluster subnet create

Create a portable classic subnet in an IBM Cloud infrastructure account on your public or private VLAN and make it available to a cluster.

Portable public IP addresses are charged monthly. If you remove portable public IP addresses after the cluster is provisioned, you still must pay the monthly charge, even if you used them only for a short amount of time.

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of IBM Cloud Kubernetes Service at the same time.

In classic clusters, if we have multiple VLANs for the cluster, multiple subnets on the same VLAN, or a multizone classic cluster, we must enable a Virtual Router Function (VRF) for the IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, contact your IBM Cloud infrastructure account representative. To check whether a VRF is already enabled, use the ibmcloud account show command. If we cannot or do not want to enable VRF, enable VLAN spanning. To perform this action, we need the Network > Manage Network VLAN Spanning infrastructure permission, or we can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud oc vlan spanning get --region <region> command.

    ibmcloud oc cluster subnet create --cluster CLUSTER --size SIZE --vlan VLAN_ID [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster. To list the clusters, use the ibmcloud oc cluster ls command.

    --size SIZE
    The number of IP addresses that we want to create in the portable subnet. Accepted values are 8, 16, 32, or 64.

    When you add portable IP addresses for the subnet, three IP addresses are used to establish cluster-internal networking. We cannot use these three IP addresses for the Ingress application load balancers (ALBs) or to create network load balancer (NLB) services. For example, if you request eight portable public IP addresses, we can use five of them to expose our apps to the public.

    --vlan VLAN_ID
    The ID of the public or private VLAN on which we want to create the subnet. You must select a public or private VLAN that an existing worker node is connected to. To review the public or private VLANs that your worker nodes are connected to, run ibmcloud oc cluster get --cluster <cluster> --show-resources and look for the Subnet VLANs section in the output. The subnet is provisioned in the same zone that the VLAN is in.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster subnet create --cluster my_cluster --size 8 --vlan 1764905



ibmcloud oc cluster subnet detach

Detach a public or private portable classic subnet in an IBM Cloud infrastructure account from a cluster. The subnet remains available in your IBM Cloud infrastructure account. Note: Any services that were deployed to an IP address from the subnet remain active after the subnet is removed.

    ibmcloud oc cluster subnet detach --cluster CLUSTER --subent-id SUBNET_ID [-f] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster. To list the clusters, use the ibmcloud oc cluster ls command.

    --vlan VLAN_ID
    The ID of the public or private subnet that we want to detach. To find the subnet ID, first run ibmcloud oc cluster get --cluster <cluster> --show-resources and look for the subnet CIDR in the Subnet VLANs section of the output. Then, using the subnet CIDR, run ibmcloud oc subnets --provider classic and look for the subnet's ID.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc cluster subnet detach --cluster my_cluster --subnet-id 1602829



Deprecated: ibmcloud oc cluster user-subnet add

Bring your own private subnet to your IBM Cloud Kubernetes Service clusters. This private subnet is not one provided by IBM Cloud infrastructure. As such, we must configure any inbound and outbound network traffic routing for the subnet.

This command is deprecated. Add an existing IBM Cloud infrastructure subnet to the cluster by running ibmcloud oc cluster subnet add.

When you make a subnet available to a cluster, IP addresses of this subnet are used for cluster networking purposes. To avoid IP address conflicts, make sure that you use a subnet with one cluster only. Do not use a subnet for multiple clusters or for other purposes outside of IBM Cloud Kubernetes Service at the same time.

In classic clusters, if we have multiple VLANs for the cluster, multiple subnets on the same VLAN, or a multizone classic cluster, we must enable a Virtual Router Function (VRF) for the IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, contact your IBM Cloud infrastructure account representative. To check whether a VRF is already enabled, use the ibmcloud account show command. If we cannot or do not want to enable VRF, enable VLAN spanning. To perform this action, we need the Network > Manage Network VLAN Spanning infrastructure permission, or we can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud oc vlan spanning get --region <region> command.

    ibmcloud oc cluster user-subnet add --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --subnet-cidr SUBNET_CIDR
    The subnet Classless InterDomain Routing (CIDR). This value is required, and must not conflict with any subnet that is used by IBM Cloud infrastructure. Supported prefixes range from /30 (1 IP address) to /24 (253 IP addresses). If you set the CIDR at one prefix length and later need to change it, first add the new CIDR, then remove the old CIDR.

    --private-vlan PRIVATE_VLAN
    Required: The ID of the private VLAN. The ID must be for a private VLAN in the cluster that one or more of the worker nodes are on. To see private VLANs in the cluster, run ibmcloud oc cluster get --cluster <cluster_name_or_ID> --show-resources. In the Subnet VLANs section of the output, look for VLANs that have a Public value of false.

Example:

    ibmcloud oc cluster user-subnet add --cluster my_cluster --subnet-cidr 169.xx.xxx.xxx/29 --private-vlan 1502175



Deprecated: ibmcloud oc cluster user-subnet rm

Remove your own private subnet from a specified cluster. Any service that was deployed with an IP address from your own private subnet remains active after the subnet is removed.

This command is deprecated. To remove an IBM Cloud infrastructure subnet from the cluster instead, run ibmcloud oc cluster subnet detach.

    ibmcloud oc cluster user-subnet rm --cluster CLUSTER --subnet-cidr SUBNET_CIDR --private-vlan PRIVATE_VLAN

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --subnet-cidr SUBNET_CIDR
    The subnet Classless InterDomain Routing (CIDR). This value is required, and must match the CIDR that was set by the ibmcloud oc cluster user-subnet add command.

    --private-vlan PRIVATE_VLAN
    The ID of the private VLAN. This value is required, and must match the VLAN ID that was set by the ibmcloud oc cluster user-subnet add command.

Example:

    ibmcloud oc cluster user-subnet rm --cluster my_cluster --subnet-cidr 169.xx.xxx.xxx/29 --private-vlan 1502175



worker commands

View and modify worker nodes for a cluster.


Deprecated: ibmcloud oc worker add

Add stand-alone worker nodes to a cluster.

This command is deprecated. Create a worker pool by running ibmcloud oc worker-pool create classic or ibmcloud oc worker-pool create vpc-gen2, or add workers to an existing worker pool by running ibmcloud oc worker-pool resize.

    ibmcloud oc worker add --cluster CLUSTER [--hardware HARDWARE] --flavor FLAVOR --workers NUMBER --private-vlan PRIVATE_VLAN --public-vlan PUBLIC_VLAN [--disable-disk-encrypt] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --hardware HARDWARE
    Optional: The level of hardware isolation for the worker node. Use dedicated so that available physical resources are dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. For bare metal flavors, specify dedicated.

    --flavor FLAVOR
    Choose a machine type, or flavor, for the worker nodes. We can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which we deploy the cluster. For more information, see the documentation for the ibmcloud oc flavors (machine-types) command. This value is required for standard clusters and is not available for free clusters.

    --workers NUMBER
    An integer that represents the number of worker nodes to create in the cluster.

    --private-vlan PRIVATE_VLAN
    Required: The private VLAN that was specified when the cluster was created. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

    --public-vlan PUBLIC_VLAN
    Optional: The public VLAN that was specified when the cluster was created. If we want your worker nodes to exist on a private VLAN only, do not provide a public VLAN ID. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

    If worker nodes are set up with a private VLAN only, we must allow worker nodes and the cluster master to communicate by enabling the private service endpoint or configuring a gateway appliance.

    --disable-disk-encrypt
    Worker nodes feature AES 256-bit disk encryption by default; learn more. To disable encryption, include this option.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker add --cluster my_cluster --workers 3 --public-vlan my_public_VLAN_ID --private-vlan my_private_VLAN_ID --flavor b3c.4x16 --hardware shared



ibmcloud oc worker get

View the details of a worker node.

    ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER_NAME_OR_ID
    Optional: The name or ID of the worker node's cluster.

    --worker WORKER_NODE_ID
    Required: The name of our worker node. Run ibmcloud oc worker ls --cluster CLUSTER to view the IDs for the worker nodes in a cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker get --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1



ibmcloud oc worker ls

List all worker nodes in a cluster.

    ibmcloud oc worker ls --cluster CLUSTER [--worker-pool POOL] [--show-pools] [--show-deleted] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster for the available worker nodes.

    -p, --worker-pool POOL
    Optional: View only worker nodes that belong to the worker pool. To list available worker pools, run ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>.

    --show-pools
    Optional: List the worker pool that each worker node belongs to.

    --show-deleted
    Optional: View worker nodes that were deleted from the cluster, including the reason for deletion.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker ls --cluster my_cluster



ibmcloud oc worker reboot

Reboot a worker node in a cluster.

During the reboot, the state of our worker node does not change. For example, we might use a reboot if the worker node status in classic IBM Cloud infrastructure is Powered Off and we need to turn on the worker node. A reboot clears temporary directories, but does not clear the entire file system or reformat the disks. The worker node IP address remains the same after the reboot operation.

Rebooting a worker node can cause data corruption on the worker node. Use this command with caution and when we know that a reboot can help recover your worker node. In all other cases, reload your worker node instead.

Before you reboot your worker node, make sure that pods are rescheduled on other worker nodes to help avoid downtime for the app or data corruption on the worker node.

  1. List all worker nodes in the cluster and note the name of the worker node that we want to remove.

      oc get nodes

    The name that is returned in this command is the private IP address that is assigned to your worker node. We can find more information about your worker node when you run the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command and look for the worker node with the same Private IP address.

  2. Force pods to be removed from your worker node and rescheduled onto remaining worker nodes in the cluster. The worker node is also cordoned, or marked as unavailable for future pod scheduling. Replace <worker_name> with the private IP address of the worker node that you previously retrieved.

      oc adm drain <worker_name>

    This process can take a few minutes.

  3. Reboot the worker node. Use the worker ID that is returned from the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command.

      ibmcloud oc worker reboot --cluster <cluster_name_or_ID> --worker <worker_name_or_ID>

  4. Wait about 5 minutes before you make your worker node available for pod scheduling to ensure that the reboot is finished. During the reboot, the state of our worker node does not change. The reboot of a worker node is usually completed in a few seconds.

  5. Make your worker node available for pod scheduling. Use the name for the worker node that is returned from the oc get nodes command.

      oc adm uncordon <worker_name>


    ibmcloud oc worker reboot [--hard] --cluster CLUSTER --worker WORKER_ID [--skip-master-healthcheck] [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --hard
    Optional: Use this option to force a hard restart of a worker node by cutting off power to the worker node. Use this option if the worker node is unresponsive or the worker node's container runtime is unresponsive.

    -w, --worker WORKER
    Specify a worker node ID. To reload multiple worker nodes, use multiple flags, such as -w worker1_id -w worker2_id.

    --skip-master-healthcheck
    Skip a health check of our master before reloading or rebooting your worker nodes.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker reboot --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2



ibmcloud oc worker reload

Reload the configurations for a worker node.

A reload can be useful if your worker node experiences problems, such as slow performance or if your worker node is stuck in an unhealthy state. During the reload, your worker node machine is updated with the latest image and data is deleted if not stored outside the worker node. The worker node public and private IP address remain the same after the reload operation.

Reloading a worker node applies patch version updates to your worker node, but not major or minor updates. To see the changes from one patch version to the next, review the Version changelog documentation.

Before you reload your worker node, make sure that pods are rescheduled on other worker nodes to help avoid a downtime for the app or data corruption on the worker node.

  1. List all worker nodes in the cluster and note the name of the worker node that we want to reload.

      oc get nodes

    The name that is returned in this command is the private IP address that is assigned to your worker node. We can find more information about your worker node when you run the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command and look for the worker node with the same Private IP address.

  2. Reload the worker node. As part of the reload process, the pods that run on the worker node are drained and rescheduled onto remaining worker nodes in the cluster. The worker node is also cordoned, or marked as unavailable for future pod scheduling. Use the worker node ID that is returned from the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command.

      ibmcloud oc worker reload --cluster <cluster_name_or_ID> --worker <worker_name_or_ID>

  3. Wait for the reload to complete. When your worker node is in a Normal state, the worker node becomes available for pod scheduling again.

    ibmcloud oc worker reload --cluster CLUSTER --worker WORKER_ID [--skip-master-healthcheck] [-f] [-q]

Supported infrastructure provider: Classic. To reload a worker node in a VPC Generation 1 compute cluster, use the ibmcloud oc worker replace command instead.

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -w, --worker WORKER
    Specify a worker node ID. To reload multiple worker nodes, use multiple flags, such as -w worker1_id -w worker2_id.

    --skip-master-healthcheck
    Skip a health check of our master before reloading or rebooting your worker nodes.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker reload --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2



ibmcloud oc worker replace

Delete a worker node and replace it with a new worker node in the same worker pool.

The replacement worker node is created in the same zone and has the same flavor as the old worker node, but might be assigned new public or private IP addresses. We might replace a worker node if we cannot reload or update the worker node, such as if it enters a troubled state.

We can also use this command to update the Kubernetes version of the worker node to match the major and minor version of the Kubernetes master by including the --update flag. If you do not include the --update flag, patch version updates are applied to your worker node, but not major or minor updates. To see the changes from one major, minor, or patch version to the next, review the Version changelog documentation. Remember that your worker nodes can be only up to two versions behind the master version (n-2).

When you replace a worker node, keep in mind the following considerations.

  • Multiple worker nodes are replaced concurrently: If you replace multiple worker nodes at the same time, they are deleted and replaced concurrently, not one by one. Make sure that we have enough capacity in the cluster to reschedule the workloads before you replace worker nodes.
  • Node-level customizations are not preserved: Any custom labels or taints that you applied at the individual worker node level are not applied to the replacement worker node. Instead, apply labels or taints at the worker pool level so that the replacement worker node gets these attributes.
  • Automatic rebalancing: A replacement worker node is not created if the worker pool does not have automatic rebalancing enabled.

Before beginning, make sure that the cluster has enough other worker nodes so that the pods can be rescheduled and continue to run.

  1. List all worker nodes in the cluster and note the name of the worker node that we want to replace.

      oc get nodes

    The name that is returned in this command is the private IP address that is assigned to your worker node. We can find more information about your worker node when you run the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command and look for the worker node with the same Private IP address.

  2. Replace the worker node. As part of the replace process, the pods that run on the worker node are drained and rescheduled onto remaining worker nodes in the cluster. The worker node is also cordoned, or marked as unavailable for future pod scheduling. Use the worker node ID that is returned from the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command.

      ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>

  3. Verify that the worker node is replaced.

      ibmcloud oc worker ls --cluster <cluster_name_or_ID>


    ibmcloud oc worker replace --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID [--update] [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service.

Command options

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --worker WORKER
    Required: The name or ID of a worker node.

    --update
    Include this flag to update the worker node to the same major and minor version of the master and the latest patch.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker replace --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1



ibmcloud oc worker rm

Remove one or more worker nodes from a cluster. If you remove a worker node, the cluster becomes unbalanced, and replacing a worker node no longer creates a replacement worker node. We can automatically rebalance your worker pool by running the ibmcloud oc worker-pool rebalance command after you remove a worker node.

    ibmcloud oc worker rm --cluster CLUSTER --worker WORKER [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -w, --worker WORKER
    Specify a worker node ID. To reload multiple worker nodes, use multiple flags, such as -w worker1_id -w worker2_id.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker rm --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2



ibmcloud oc worker update

Update worker nodes to apply the latest security updates and patches to the operating system, and to update the Kubernetes version to match the version of the Kubernetes master. We can update the master Kubernetes version with the ibmcloud oc cluster master update command. Remember that your worker nodes can be only up to two versions behind the master version (n-2). The worker node IP address remains the same after the update operation.

Running ibmcloud oc worker update can cause downtime for our apps and services. During the update, all pods are rescheduled onto other worker nodes, the worker node is reimaged, and data is deleted if not stored outside the pod. To avoid downtime, ensure that we have enough worker nodes to handle the workload while the selected worker nodes are updating.

We might need to change your YAML files for deployments before you update. Review this release note for details.

    ibmcloud oc worker update --cluster CLUSTER --worker WORKER_ID [-f] [-q]

Supported infrastructure provider: Classic. To update a worker node in a VPC Generation 1 compute cluster, use the ibmcloud oc worker replace command instead.

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where you list available worker nodes.

    -w, --worker WORKER
    Specify a worker node ID. To reload multiple worker nodes, use multiple flags, such as -w worker1_id -w worker2_id.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker update --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2



worker-pool commands

View and modify worker pools for a cluster.


ibmcloud oc worker-pool create classic

We can create a worker pool in the cluster. When you add a worker pool, it is not assigned a zone by default. You specify the number of workers that we want in each zone and the flavors for the workers. The worker pool is given the default Kubernetes versions. To finish creating the workers, add a zone or zones to your pool.

    ibmcloud oc worker-pool create classic --name POOL_NAME --cluster CLUSTER --flavor FLAVOR --size-per-zone WORKERS_PER_ZONE --hardware ISOLATION [--disable-disk-encrypt] [--label KEY1=VALUE1] [--entitlement cloud_pak] [-q] [--output json]

Supported infrastructure provider: Classic. To create a worker pool in a VPC Generation 2 compute cluster, use the ibmcloud oc worker-pool create vpc-gen2 command.

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --name POOL_NAME
    The name that we want to give your worker pool.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --flavor FLAVOR
    Choose a machine type, or flavor. We can deploy your worker nodes as virtual machines on shared or dedicated hardware, or as physical machines on bare metal. Available physical and virtual machines types vary by the zone in which we deploy the cluster. For more information, see the documentation for the ibmcloud oc flavors (macine-types) command. This value is required for standard clusters and is not available for free clusters.

    --size-per-zone WORKERS_PER_ZONE
    The number of workers to create in each zone. This value is required, and must be 2 or greater. For more information, see What is the smallest size cluster that I can make?.

    --hardware ISOLATION
    Required: The level of hardware isolation for the worker node. Use dedicated if we want to have available physical resources that are dedicated to you only, or shared to allow physical resources to be shared with other IBM customers. The default is shared. For bare metal flavors, specify dedicated.

    --disable-disk-encrpyt
    Specifies that the disk is not encrypted. The default value is false.

    -l, --label KEY1=VALUE1
    Optional: Apply key-value labels to each worker node in the worker pool. To specify multiple labels, use multiple flags, such as -l key1=value1 -l key2=value2.

    --entitlement cloud_pak
    Include this flag only if you use this cluster with an IBM Cloud Pak™ that has an OpenShift entitlement. When you specify the number of workers (--size-per-zone) and flavor (--flavor), make sure to specify only the number and size of worker nodes that we are entitled to use in IBM Passport Advantage{: external}. After creation, your worker pool does not charge you the OpenShift license fee for the entitled worker nodes.

    Do not exceed your entitlement. Keep in mind that the OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what we are entitled to use. For example, we might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and we cannot use the same entitlement for other worker pools, cloud providers, or environments.

    -q
    Optional: Do not show the message of the day or update reminders.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc worker-pool create classic --name my_pool --cluster my_cluster --flavor b3c.4x16 --size-per-zone 6



ibmcloud oc worker-pool create vpc-gen2

Add a worker pool to a VPC Generation 2 compute cluster. No worker nodes are created until you add zones to the worker pool.

    ibmcloud oc worker-pool create vpc-gen2 --name <worker_pool_name> --cluster <cluster_name_or_ID> --flavor <flavor> --size-per-zone <number_of_workers_per_zone> [--vpc-id <VPC ID>] [--label KEY1=VALUE1] [--entitlement cloud_pak] [-q] [--output json]

Supported infrastructure provider: VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service.

Command options

    --name NAME
    Required: Set the name for the worker pool.

    -c, --cluster CLUSTER
    Required: Specify the name or ID of the cluster. To list VPC clusters, run ibmcloud oc cluster ls --provider vpc-gen2.

    --size-per-zone NUMBER_WORKERS_PER_ZONE
    Specify the number of worker nodes to create per zone in this worker pool. No worker nodes are created until you add zones to the worker pool. This value is required, and must be 2 or greater. For more information, see What is the smallest size cluster that I can make?.

    --flavor FLAVOR
    Choose a flavor for the worker nodes. We can deploy your worker nodes as virtual machines on shared or dedicated hardware. To see flavors that are available in a VPC zone, run ibmcloud oc flavors --zone <vpc_zone> --provider vpc-gen2.

    --vpc-id VPC_ID
    Optional: Specify the ID of the VPC in which to create the worker pool's worker nodes. The value must match the VPC ID that the cluster is in. To list the cluster's VPC ID, run ibmcloud oc cluster get -c <cluster_name_or_ID>. If this flag is not provided, then the worker pool defaults to the VPC ID of existing worker pools in the cluster.

    -l, --label KEY1=VALUE1
    Optional: Apply key-value labels to each worker node in the worker pool. To specify multiple labels, use multiple flags, such as -l key1=value1 -l key2=value2.

    --entitlement cloud_pak
    Include this flag only if you use this cluster with an IBM Cloud Pak™ that has an OpenShift entitlement. When you specify the number of workers (--size-per-zone) and flavor (--flavor), make sure to specify only the number and size of worker nodes that we are entitled to use in IBM Passport Advantage{: external}. After creation, your worker pool does not charge you the OpenShift license fee for the entitled worker nodes.

    Do not exceed your entitlement. Keep in mind that the OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what we are entitled to use. For example, we might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and we cannot use the same entitlement for other worker pools, cloud providers, or environments.

    -q
    Optional: Do not show the message of the day or update reminders.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc worker-pool create vpc-gen2 --name my_pool --cluster my_cluster --flavor bx2.4x16 --size-per-zone 3



ibmcloud oc worker-pool get

View the details of a worker pool.

    ibmcloud oc worker-pool get --worker-pool WORKER_POOL --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -p, --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to view the details of. To list available worker pools, run ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where the worker pool is located.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker-pool get --worker-pool pool1 --cluster my_cluster



ibmcloud oc worker-pool ls

List all worker pools in a cluster.

    ibmcloud oc worker-pool ls --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER_NAME_OR_ID
    Required: The name or ID of the cluster for which we want to list worker pools.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker-pool ls --cluster my_cluster



ibmcloud oc worker-pool rebalance

Rebalance a worker pool in a cluster after you delete a worker node. When you run this command, a new worker or workers are added to your worker pool so that the worker pool has the same number of nodes per zone that you specified.

    ibmcloud oc worker-pool rebalance --cluster CLUSTER --worker-pool WORKER_POOL [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -p, --worker-pool WORKER_POOL
    Required: The worker pool that we want to rebalance.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker-pool rebalance --cluster my_cluster --worker-pool my_pool



ibmcloud oc worker-pool resize

Resize your worker pool to increase or decrease the number of worker nodes that are in each zone of the cluster. Your worker pool must have at least 2 worker nodes per zone.

    ibmcloud oc worker-pool resize --cluster CLUSTER --worker-pool WORKER_POOL --size-per-zone WORKERS_PER_ZONE [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster for which we want to resize worker pools.

    --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to update.

    --size-per-zone WORKERS_PER_ZONE
    The number of workers that we want to have in each zone. This value is required, and must be 1 or greater. For more information, see What is the smallest size cluster that I can make?.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker-pool resize --cluster my_cluster --worker-pool my_pool --size-per-zone 3



ibmcloud oc worker-pool rm

Remove a worker pool from the cluster. All worker nodes in the pool are deleted. Your pods are rescheduled when you delete. To avoid downtime, be sure that we have enough workers to run the workload.

    ibmcloud oc worker-pool rm --worker-pool WORKER_POOL --cluster CLUSTER [-q] [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -p, --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to remove.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster that we want to remove the worker pool from.

    -q
    Optional: Do not show the message of the day or update reminders.

    -f
    Optional: Force the command to run with no user prompts.

Example:

    ibmcloud oc worker-pool rm --cluster my_cluster --worker-pool pool1



ibmcloud oc worker-pool taint

Set or remove Kubernetes taints for all the worker nodes in a worker pool. After you set up taints, pods without a matching toleration cannot run on the worker pool. We might use taints to dedicate your worker pool exclusively for a certain type of workload, such as for networking edge nodes or the cluster autoscaler. For more information about how taints and tolerations work, see the Kubernetes documentation.


ibmcloud oc worker-pool taint set

Set Kubernetes taints for all the worker nodes in a worker pool. Taints prevent pods without matching tolerations from running on the worker nodes. After you set your custom taint for the worker pool, confirm that the taints are set on the worker nodes by getting the private IP address of the worker node (ibmcloud oc worker ls -c <cluster_name_or_ID>) and running oc describe node <worker_private_IP>.

When you set taints for the worker pool, any custom taints that you previously set with this command are overwritten. To keep the existing custom taints and set new taints, check the worker pool's existing taints and include them when you rerun this command.

    ibmcloud oc worker-pool taint set --worker-pool WORKER_POOL --cluster CLUSTER --taint KEY=VALUE:EFFECT [--taint KEY=VALUE2:EFFECT] [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -p, --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to add the taint to. To list available worker pools, run ibmcloud oc worker-pool ls -c <cluster_name_or_ID>.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster with the worker pool that we want to taint.

    --taint KEY=VALUE:EFFECT
    Required: The label and effect for the Kubernetes taint that we want to set for the worker pool. Specify the taint in the format key=value:effect. The key=value is a label pair such as env=prod that you use to manage the worker node taint and matching pod tolerations. The effect is a Kubernetes taint effect{: external} such as NoSchedule, PreferNoSchedule, or NoExecute that describes how the taint works. Depending on the effect of the taint that you set, pods that are running on the worker nodes might be evicted.

    -f
    Optional: Force the command to run with no user prompts.

Example:

    ibmcloud oc worker-pool taint set --cluster my_cluster --worker-pool pool1 --taint env=prod:NoSchedule



ibmcloud oc worker-pool taint rm

Remove all Kubernetes taints for all the worker nodes in a worker pool. To check the taints before you remove them, run ibmcloud oc worker-pool get -c <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>.

When you remove taints for the worker pool, all Kubernetes taints are removed from the worker pool and its worker nodes. To remove an individual taint from all worker nodes, rerun the ibmcloud oc worker-pool taint set command and include only the taints that we want to keep. Or, use oc taint node <worker_privateIP> key:effect- command to remove a taint from an individual worker node.

    ibmcloud oc worker-pool taint rm --worker-pool WORKER_POOL --cluster CLUSTER [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -p, --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to add the taint to. To list available worker pools, run ibmcloud oc worker-pool ls -c <cluster_name_or_ID>.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster with the worker pool that we want to taint.

    -f
    Optional: Force the command to run with no user prompts.

Example:

    ibmcloud oc worker-pool taint rm --cluster my_cluster --worker-pool pool1


ibmcloud oc worker-pool zones

View the zones that are attached to a worker pool.

    ibmcloud oc worker-pool zones --worker-pool WORKER_POOL --cluster CLUSTER [-q] [-f]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where the worker pool exists.

    -p, --worker-pool WORKER_POOL
    Required: The name of the worker node pool that we want to see zones for.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc worker-pool zones --cluster my_cluster --worker-pool pool1



zone commands


ibmcloud oc zone add classic

After creating a classic cluster or worker pool, we can add a zone. When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. We can add more than one zone only if the cluster is in a multizone metro.

    ibmcloud oc zone add classic --zone ZONE --cluster CLUSTER --worker-pool WORKER_POOL --private-vlan PRIVATE_VLAN [--public-vlan PUBLIC_VLAN] [--output json] [-q]

Supported infrastructure provider: Classic. To add a zone to worker pools in a VPC Generation 2 compute cluster, use the ibmcloud oc zone add vpc-gen2 command.

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --zone ZONE
    Required: The zone that we want to add. It must be a multizone-capable zone within the cluster's region.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -p, --worker-pool WORKER_POOL
    The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple flags, such as -p pool1 -p pool2.

    --private-vlan PRIVATE_VLAN

    The ID of the private VLAN. This value is conditional.

    If we have a private VLAN in the zone, this value must match the private VLAN ID of one or more of the worker nodes in the cluster. To see the VLANs that we have available, run ibmcloud oc cluster get --cluster <cluster> --show-resources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

    If you do not have a private or public VLAN in that zone, do not specify this option. A private and a public VLAN are automatically created for you when you initially add a zone to your worker pool.

    In classic clusters, if we have multiple VLANs for the cluster, multiple subnets on the same VLAN, or a multizone classic cluster, we must enable a Virtual Router Function (VRF) for the IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, contact your IBM Cloud infrastructure account representative. To check whether a VRF is already enabled, use the ibmcloud account show command. If we cannot or do not want to enable VRF, enable VLAN spanning. To perform this action, we need the Network > Manage Network VLAN Spanning infrastructure permission, or we can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud oc vlan spanning get --region <region> command.

    --public-vlan PUBLIC_VLAN

    The ID of the public VLAN. This value is required if we want to expose workloads on the nodes to the public after you create the cluster. It must match the public VLAN ID of one or more of the worker nodes in the cluster for the zone. To see the VLANs that we have available, run ibmcloud oc cluster get --cluster <cluster> --show-resources. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

    If you do not have a private or public VLAN in that zone, do not specify this option. A private and a public VLAN are automatically created for you when you initially add a zone to your worker pool.

    In classic clusters, if we have multiple VLANs for the cluster, multiple subnets on the same VLAN, or a multizone classic cluster, we must enable a Virtual Router Function (VRF) for the IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, contact your IBM Cloud infrastructure account representative. To check whether a VRF is already enabled, use the ibmcloud account show command. If we cannot or do not want to enable VRF, enable VLAN spanning. To perform this action, we need the Network > Manage Network VLAN Spanning infrastructure permission, or we can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud oc vlan spanning get --region <region> command.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc zone add classic --zone dal10 --cluster my_cluster -w pool1 -w pool2 --private-vlan 2294021



ibmcloud oc zone add vpc-gen2

After creating a Generation 2 VPC cluster or worker pool, we can add a zone. When you add a zone, worker nodes are added to the new zone to match the number of workers per zone that you specified for the worker pool. We can add more than one zone only if the cluster is in a multizone metro.

    ibmcloud oc zone add vpc-gen2 --zone ZONE --subnet-id VPC_SUBNET_ID --cluster CLUSTER --worker-pool WORKER_POOL [--output json] [-q]

Supported infrastructure provider: VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --zone ZONE
    Required: The zone that we want to add. It must be a VPC zone within the cluster's region. To see available VPC zones, run ibmcloud oc zone ls --provider vpc-gen2.

    --subnet-id SUBNET_ID
    Required: The ID of the subnet that we want to add. The VPC subnet must be within the zone that you specify. To see available VPC subnets, run ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <vpc_zone>. VPC subnets provide IP addresses for the worker nodes and load balancer services in the cluster, so use a VPC subnet with enough IP addresses, such as 256.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster. To list VPC clusters, run ibmcloud oc cluster ls --provider vpc-gen2.

    -p, --worker-pool WORKER_POOL
    The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple flags, such as -p pool1 -p pool2.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc zone add vpc-gen2 --zone us-south-3 --cluster my_cluster -w pool1 -w pool2



ibmcloud oc zone ls

View a list of available zones that we can create a cluster in.

This command works for both classic and VPC clusters.

The locations alias for this command is deprecated.

    ibmcloud oc zone ls --provider classic [--location LOCATION] [--region-only] [--output json] [-q]

Minimum permissions: None

Command options:

    --provider classic
    The infrastructure provider type to list zones for. This flag is required.

    -l, --location LOCATION
    Filter output by a specific location. To see supported locations, run ibmcloud oc locations. To specify multiple locations, use one flag for each location, such as -l dal -l seo.

    --region-only
    Optional: List multizones only within the region that we are logged in to.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc zone ls -l ap



ibmcloud oc zone network-set

Multizone classic clusters only: Set the network metadata for a worker pool to use a different public or private VLAN for the zone than it previously used. Worker nodes that were already created in the pool continue to use the previous public or private VLAN, but new worker nodes in the pool use the new network data.

    ibmcloud oc zone network-set --zone ZONE --cluster CLUSTER --worker-pool WORKER_POOL --private-vlan PRIVATE_VLAN [--public-vlan PUBLIC_VLAN] [-f] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --zone ZONE
    Required: The zone that we want to add. It must be a multizone-capable zone within the cluster's region.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -p, --worker-pool WORKER_POOL
    The name of the worker pool to add the zone to. To specify multiple worker pools, use multiple flags, such as -p pool1 -p pool2.

    --private-vlan PRIVATE_VLAN
    The ID of the private VLAN. This value is required, whether we want to use the same or a different private VLAN than the one that you used for the other worker nodes. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

    The private and public VLANs must be compatible, which we can determine from the Router ID prefix.

    --public-vlan PUBLIC_VLAN
    The ID of the public VLAN. This value is required only if we want to change the public VLAN for the zone. To change the public VLAN, we must always provide a compatible private VLAN. New worker nodes are added to the VLAN that you specify, but the VLANs for any existing worker nodes are not changed.

    The private and public VLANs must be compatible, which we can determine from the Router ID prefix.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Usage:

  1. Check the VLANs that are available in the cluster.

      ibmcloud oc cluster get --cluster <cluster_name_or_ID> --show-resources

    Example output:

      Subnet VLANs VLAN ID Subnet CIDR Public User-managed 229xxxx 169.xx.xxx.xxx/29 true false 229xxxx 10.xxx.xx.x/29 false false

  2. Check that the public and private VLAN IDs that we want to use are compatible. To be compatible, the Router must have the same pod ID. Private VLAN routers always begin with bcr (back-end router) and public VLAN routers always begin with fcr (front-end router). When you create a cluster and specify the public and private VLANs, the number and letter combination after those prefixes must match.

      ibmcloud oc vlan ls --zone <zone>

    In the example output, note that Router pod IDs match: 01a and 01a. If one pod ID was 01a and the other was 02a, we cannot set these public and private VLAN IDs for your worker pool.

      ID Name Number Type Router Supports Virtual Workers 229xxxx 1234 private bcr01a.dal12 true 229xxxx 5678 public fcr01a.dal12 true

  3. If you do not have any VLANs available, we can order new VLANs.

Example:

    ibmcloud oc zone network-set --zone dal10 -c my_cluster -p pool1 -p pool2 --private-vlan 2294021



ibmcloud oc zone rm

Multizone clusters only: Remove a zone from one or more worker pools in the cluster. All worker nodes in the worker pool for this zone are deleted.

Before you remove a zone, make sure that we have enough worker nodes in other zones in the cluster so that the pods can reschedule. Rescheduling the pods can avoid a downtime for the app or data corruption on the worker node.

    ibmcloud oc zone rm --cluster CLUSTER --zone ZONE [--worker-pool WORKER_POOL] [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Operator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --zone ZONE
    Required: The zone that we want to remove.

    -p, --worker-pool WORKER_POOL
    The name of the worker pool to remove the zone from. To specify multiple worker pools, use multiple flags, such as -p pool1 -p pool2. To remove the zone from all worker pools in the cluster, do not include this flag.

    -f
    Optional: Force the command to run with no user prompts.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc zone rm --zone dal10 --cluster my_cluster



ingress commands

View and configure Ingress application load balancers (ALBs).

In CLI version 1.0.157 and later, the ibmcloud oc alb category is deprecated, and these commands are now listed in the ibmcloud oc ingress alb subcategory. For more information, see the CLI changelog.


ibmcloud oc ingress alb autoupdate disable

Disable automatic updates of all Ingress ALB pods in a cluster.

By default, automatic updates to Ingress application load balancers (ALBs) are enabled. ALB pods are automatically updated when a new image version is available. To instead update the add-on manually, use this command to disable automatic updates. We can then update ALB pods by running the ibmcloud oc ingress alb update command.

When you update the major or minor Kubernetes version of the cluster, IBM automatically makes necessary changes to the Ingress deployment, but does not change the image version of our Ingress ALB add-on. You are responsible for checking the compatibility of the latest Kubernetes versions and your Ingress ALB add-on images.

    ibmcloud oc ingress alb autoupdate disable --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb autoupdate disable --cluster mycluster



ibmcloud oc ingress alb autoupdate enable

Enable automatic updates of all Ingress ALB pods in a cluster.

If automatic updates for the Ingress ALB add-on are disabled, we can re-enable automatic updates. Whenever the next image version becomes available, the ALBs are automatically updated to the latest build.

    ibmcloud oc ingress alb autoupdate enable --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc ingress alb autoupdate get

Check whether automatic updates for the Ingress ALB add-on are enabled and whether your ALBs are updated to the latest image version.

    ibmcloud oc ingress alb autoupdate get --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc ingress alb create classic

Version 3.11 clusters only: Create a public or private ALB in a classic cluster. The ALB that you create is enabled by default.

    ibmcloud oc ingress alb create classic --cluster CLUSTER --type (PUBLIC|PRIVATE) --vlan VLAN_ID --zone ZONE [--ip IP] [--version IMAGE_VERSION] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    The name or ID of the cluster.

    --type (PUBLIC|PRIVATE)
    The type of ALB: public or private. This type must match the vlan.

    --vlan VLAN_ID
    The ID of the VLAN to create the ALB on. This VLAN must match the ALB type and must be in the same zone as the ALB that we want to create.

    --zone ZONE
    The zone to create the ALB in.

    --ip IP
    Optional: An IP address to assign to the ALB. This IP must be on the vlan that you specified and must be in the same zone as the ALB that we want to create. This IP address must not be in use by another load balancer or ALB in the cluster. To see the IP addresses that are currently in use, run oc get svcs --all-namespaces.

    --version IMAGE_VERSION
    Optional: The version of the image that we want the ALB to run. To list available versions, run ibmcloud oc ingress alb versions. To specify a version other than the default, we must first disable automatic updates by running the ibmcloud oc ingress alb autoupdate disable command. If you omit this flag, the ALB runs the default version of the Kubernetes Ingress image type.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb create classic --cluster mycluster --type public --vlan 2234945 --zone dal10 --ip 1.1.1.1 --version 652



ibmcloud oc ingress alb disable

Disable an ALB in the cluster. The ALB and its pods still exist, but stop routing traffic to our apps.

The previous alias for this command, ibmcloud oc ingress alb configure, is deprecated.

    ibmcloud oc ingress alb disable --alb ALB_ID --cluster CLUSTER [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --alb ALB_ID
    Required: The ID for an ALB. To view the IDs for the ALBs in a cluster, run ibmcloud oc ingress alb ls --cluster CLUSTER.

    -c, --cluster CLUSTER
    The name or ID of the cluster.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb disable --alb public-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --cluster mycluster



ibmcloud oc ingress alb enable classic

Enable an ALB in your classic cluster.

The previous alias for this command, ibmcloud oc ingress alb configure classic, is deprecated.

We can use this command to:

  • Enable a default private ALB. When you create a cluster, a default private ALB is created for you in each zone where we have workers and an available private subnet, but the default private ALBs are not enabled. However, all default public ALBs are automatically enabled, and any public or private ALBs that you create with the ibmcloud oc ingress alb create classic command are enabled by default too.
  • Enable an ALB that you previously disabled.

    ibmcloud oc ingress alb enable classic --alb ALB_ID --cluster CLUSTER [--ip IP_ADDRESS] [--version IMAGE_VERSION] [-q]

Supported infrastructure provider: Classic.

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --alb ALB_ID
    Required: The ID for an ALB. To view the IDs for the ALBs in a cluster, run ibmcloud oc ingress alb ls --cluster CLUSTER.

    -c, --cluster CLUSTER
    The name or ID of the cluster.

    --ip IP_ADDRESS
    Optional: Specify an IP address that is on a VLAN in the zone that the ALB was created in. The ALB is enabled with and uses this public or private IP address.

    This IP address must not be in use by another load balancer or ALB in the cluster. If no IP address is provided, the ALB is deployed with a public or private IP address from the portable public or private subnet that was provisioned automatically when you created the cluster, or if you re-enable an ALB that was previously enabled, the public or private IP address that was previously assigned to the ALB.

    --version IMAGE_VERSION
    Optional: The version of the image that we want the ALB to run. To list available versions, run ibmcloud oc ingress alb versions. To specify a version other than the default, we must first disable automatic updates by running the ibmcloud oc ingress alb autoupdate disable command. If you omit this flag, the ALB runs the default version of the same image that the ALB previously ran: either the Kubernetes Ingress image or the Red Hat OpenShift on IBM Cloud Ingress image.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb enable classic --alb private-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --cluster mycluster --ip 169.XX.XXX.XX --version 0.35.0_474_iks



ibmcloud oc ingress alb get

Version 3.11 clusters only: View the details of an Ingress ALB in a cluster.

    ibmcloud oc ingress alb get --alb ALB_ID --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --alb ALB_ID
    Required: The ID for an ALB. To view the IDs for the ALBs in a cluster, run ibmcloud oc ingress alb ls --cluster CLUSTER.

    -c, --cluster CLUSTER
    The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb get --alb public-cr18a61a63a6a94b658596aa93a087aaa9-alb1 --cluster mycluster



ibmcloud oc ingress alb ls

Version 3.11 clusters only: List all Ingress ALB IDs in a cluster and view whether an update for the ALB pods is available.

If no ALB IDs are returned, then the cluster does not have a portable subnet. We can create or add subnets to a cluster. Afterward, ALBs are automatically created for you.

    ibmcloud oc ingress alb ls --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where you list available ALBs.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb ls --cluster my_cluster



Beta: ibmcloud oc ingress alb migrate clean

Version 3.11 clusters only: Clean up any Ingress resources and configmaps that you no longer need, such as after an Ingress migration.

    ibmcloud oc ingress alb migrate clean --cluster CLUSTER [--generated-resources] [--iks-ingresses] [--kube-ingresses] [--reset-kube-controller-configmap] [--test-ingresses] [-f] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to check the migration status.

    --generated-resources
    Delete all resources that were automatically generated during an Ingress migration, including the Ingress resources and configmaps listed in the Migrated to sections in the output of ibmcloud oc ingress alb migrate status.

    --iks-ingresses
    Delete Ingress resources of class iks-nginx, class nginx, or of no class for public or private ALBs that run the Red Hat OpenShift on IBM Cloud Ingress image.

    --kube-ingresses
    Delete automatically generated and manually created Ingress resources of class public-iks-k8s-nginx or private-iks-k8s-nginx for public or private ALBs that run the Kubernetes Ingress image.

    --reset-kube-controller-configmap
    Reset the ibm-k8s-controller-config configmap to the default settings. The configmap is deleted and redeployed.

    --test-ingresses
    Delete automatically generated and manually created Ingress resources of class test for the test ALB service running the Kubernetes Ingress image.

    -f
    Optional: Force the command to run with no user prompts. If you do not include this flag, we are prompted for each type of resource to be deleted.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb migrate clean -c my_cluster --reset-kube-controller-configmap --test-ingresses -f



Beta: ibmcloud oc ingress alb migrate start

Version 3.11 clusters only: Start a migration of our Ingress configmap and resources that are formatted for use with ALBs that run the Red Hat OpenShift on IBM Cloud Ingress to instead use with ALBs that run the Kubernetes Ingress image. Note that this command helps you create all the resources for ALBs that run Kubernetes Ingress, but afterward we must still manually change your ALB from one type of image to another. For more information about how to prepare for a migration, see Changing the image of existing ALBs.

    ibmcloud oc ingress alb migrate start --cluster CLUSTER --type (test | test-with-private | production) [-f] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to start a migration of the Ingress configmap and resources.

    --type (test | test-with-private | production)
    The type of migration: a test migration for public Ingress routing, a test migration with private Ingress routing, or a production migration of all Ingress routing. To see the resources that are created by and the processes for each type of migration, see Changing the image of existing ALBs.

    -f
    Optional: Force the command to run with no user prompts./dd>

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb migrate start --type test --cluster my_cluster



Beta: ibmcloud oc ingress alb migrate status

Version 3.11 clusters only: Check the status of a migration of our Ingress configmap and resources.

    ibmcloud oc ingress alb migrate status --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to check the migration status.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress alb migrate status --cluster my_cluster --output json



ibmcloud oc ingress alb update

Version 3.11 clusters only: Force an update of the pods for individual or all Ingress ALBs in the cluster to the latest or a specific version.

If automatic updates for the Ingress ALB add-on are disabled and we want to update the add-on, we can force a one-time update of our ALB pods. If your ALB pods were recently updated, but a custom configuration for the ALBs is affected by the latest build, we can also use this command to roll back ALB pods to an earlier, supported version. Note that we can use this command to update your ALB image to a different version, but we cannot use this command to change your ALB from one type of image to another. After you force a one-time update, automatic updates remain disabled, but can be re-enabled with the ibmcloud oc ingress alb autoupdate enable command.

    ibmcloud oc ingress alb update --cluster CLUSTER [--alb ALB1_ID --alb ALB2_ID ...] [--version IMAGE_VERSION] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to update the ALBs.

    --alb CLUSTER
    Optional: The ID of the individual ALB to update. To list ALB IDs, run ibmcloud oc ingress alb ls -c <cluster>. To update multiple ALBs, use multiple flags, such as --alb ALB1_ID --alb ALB2_ID. If you omit this flag, all ALBs in the cluster are updated.

    --version IMAGE_VERSION
    Optional: The version of the image that we want to update ALBs to. Note that we cannot use this flag to change your ALB from one type of image to another. To list available versions, run ibmcloud oc ingress alb versions. If you omit this flag, ALBs are updated to the latest version of the image type.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example commands:

  • To update all ALB pods in the cluster:

      ibmcloud oc ingress alb update -c mycluster --version 652

  • To update the ALB pods for one or more specific ALBs:

      ibmcloud oc ingress alb update -c mycluster --version 652 --alb public-crdf253b6025d64944ab99ed63bb4567b6-alb1


ibmcloud oc ingress alb versions

Version 3.11 clusters only: View the available images and image versions for Ingress ALBs in the cluster.

As of 24 August 2020, Red Hat OpenShift on IBM Cloud supports two types of NGINX Ingress controller images for the ALB: the Red Hat OpenShift on IBM Cloud Ingress image, and the Kubernetes Ingress image. The latest three version of each image type are supported for ALBs.

  • The Red Hat OpenShift on IBM Cloud Ingress image is a custom implementation that is built on the NGINX Ingress controller.
  • The Kubernetes Ingress image is built on the community Kubernetes project's implementation of the NGINX Ingress controller.

    ibmcloud oc ingress alb versions [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.



Beta: ibmcloud oc ingress secret create

Create an Ingress secret in a cluster for a certificate that is stored in IBM Cloud Certificate Manager.

The previous alias for this command, ibmcloud oc ingress alb cert deploy, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory. For more information, see the CLI changelog.

    ibmcloud oc ingress secret create --cert-crn CERTIFICATE_CRN --cluster CLUSTER --name SECRET_NAME [--namespace NAMESPACE] [--persist] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options

    --cert-crn CERTIFICATE_CRN
    Required: The certificate CRN.

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --name SECRET_NAME
    Required: Specify a name for the secret. Make sure that you do not create the secret with the same name as the IBM-provided Ingress secret, which we can find by running ibmcloud oc cluster get --cluster <cluster_name_or_ID> | grep Ingress.

    --namespace NAMESPACE
    Optional: Specify the project that your Ingress resource is deployed to. If your ALB runs the Kubernetes Ingress image, this value is required, because the ALB can identify secrets only in the same project as your Ingress resource. If your ALB runs the Red Hat OpenShift on IBM Cloud Ingress image, and you do not specify a project, the certificate secret is created in a project called ibm-cert-store. A reference to this secret is then created in the default project, which any Ingress resource in any project can access. While processing requests, the ALB follows the reference to pick up and use the certificate secret from the ibm-cert-store project.

    --persist
    Optional: Persist the secret data in the cluster. If the secret is later deleted from the CLI or OpenShift web console, the secret is automatically re-created in the cluster. To permanently delete the secret, we must use the /ingress/v2/secret/deleteSecret API.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress secret create --cert-crn crn:v1:staging:public:cloudcerts:us-south:a/06580c923e40314421d3b6cb40c01c68:0db4351b-0ee1-479d-af37-56a4da9ef30f:certificate:4bc35b7e0badb304e60aef00947ae7ff --cluster my_cluster --name my_alb_secret --namespace demo_ns



Beta: ibmcloud oc ingress secret get

View information about Ingress secrets in the cluster, including secrets that you imported for a certificate from IBM Cloud Certificate Manager.

The previous alias for this command, ibmcloud oc ingress alb cert get, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory. For more information, see the CLI changelog.

    ibmcloud oc ingress secret get --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --name SECRET_NAME
    Required: The name of the secret.

    --namespace NAMESPACE
    Required: The project that the secret is deployed to.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress secret get --cluster my_cluster --name my_alb_secret --namespace demo_ns



Beta: ibmcloud oc ingress secret ls

List Ingress secrets in the cluster, including secrets that you imported for a certificate from IBM Cloud Certificate Manager.

The previous alias for this command, ibmcloud oc ingress alb cert ls, is deprecated.

    ibmcloud oc ingress secret ls --cluster CLUSTER [--show-deleted] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --show-deleted
    Optional: View secrets that were deleted from the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress secret ls --cluster my_cluster



Beta: ibmcloud oc ingress secret rm

Delete an Ingress secret from the cluster. If you created a secret for a certificate from IBM Cloud Certificate Manager, only the secret in the cluster is deleted and the certificate remains in your IBM Cloud Certificate Manager instance.

The previous alias for this command, ibmcloud oc ingress alb cert rm, is deprecated. In CLI version 1.0.157 and later, the ibmcloud oc ingress alb cert category is deprecated, and these commands are now listed in the ibmcloud oc ingress secret subcategory. For more information, see the CLI changelog.

    ibmcloud oc ingress secret rm --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --name SECRET_NAME
    Required: The name of the secret.

    --namespace NAMESPACE
    Required: The project that the secret is deployed to.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress secret rm --cluster my_cluster --name my_alb_secret --namespace demo_ns



Beta: ibmcloud oc ingress secret update

Update an Ingress secret for a certificate that is not hosted in the default Certificate Manager instance that was created for the cluster.

Any changes that you make to a certificate in the default Certificate Manager instance that was created for the cluster, which is named in the format kube-<cluster_ID>, are automatically reflected in the secret in your cluster. If you make changes to a certificate that is not hosted in the cluster's Certificate Manager instance, we must use this command to update the secret in the cluster the pick up the certificate changes.

    ibmcloud oc ingress secret update --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--cert-crn CRN] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --name SECRET_NAME
    Required: The name of the secret. To see available secrets, run ibmcloud oc ingress secret ls.

    --namespace NAMESPACE
    Required: The project that the secret is deployed to. To see the secret namespace, run ibmcloud oc ingress secret get --cluster --name secret_name> --namespace .

    --cert-crn CERTIFICATE_CRN
    Optional: The certificate CRN. To see the secret CRN, run ibmcloud oc ingress secret get --cluster --name secret_name> --namespace .

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress secret update --cluster my_cluster --name my_alb_secret --namespace demo_ns



ibmcloud oc ingress status

Get the status of the health of Ingress resources for a cluster.

    ibmcloud oc ingress status --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc ingress status --cluster mycluster




logging commands

Forward logs from the cluster to an external server.


ibmcloud oc logging autoupdate disable

Disable automatic updates of all Fluentd pods in a cluster.

This command works for both classic and VPC clusters.

Disable automatic updates of our Fluentd pods in a specific cluster. When you update the major or minor Kubernetes version of the cluster, IBM automatically makes necessary changes to the Fluentd configmap, but does not change the image version of our Fluentd for logging add-on. You are responsible for checking the compatibility of the latest Kubernetes versions and your add-on images.

    ibmcloud oc logging autoupdate disable --cluster CLUSTER [-q]

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to disable automatic updates for the Fluentd add-on.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc logging autoupdate enable

Enable automatic updates for the Fluentd pods in a specific cluster. Fluentd pods are automatically updated when a new image version is available.

This command works for both classic and VPC clusters.

    ibmcloud oc logging autoupdate enable --cluster CLUSTER [-q]

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to enable automatic updates for the Fluentd add-on.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc logging autoupdate get

View whether your Fluentd pods are set to automatically update in a cluster.

This command works for both classic and VPC clusters.

    ibmcloud oc logging autoupdate get --cluster CLUSTER [--output json] [-q]

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster where we want to check whether automatic updates for the Fluentd add-on are enabled.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.



ibmcloud oc logging collect

Make a request for a snapshot of our logs at a specific point in time and then store the logs in an IBM Cloud Object Storage bucket.

    ibmcloud oc logging collect --cluster CLUSTER --cos-bucket BUCKET_NAME --cos-endpoint ENDPOINT --hmac-key-id HMAC_KEY_ID --hmac-key HMAC_KEY --type LOG_TYPE [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    The name or ID of the cluster that we want to create a snapshot for.

    --cos-bucket BUCKET_NAME
    The name of the Object Storage bucket that we want to store your logs in.

    --cos-endpoint ENDPOINT
    The regional, cross regional, or single data center Object Storage endpoint for the bucket that we are storing your logs in. For available endpoints, see Endpoints and storage locations in the Object Storage documentation.

    --hmac-key-id HMAC_KEY_ID
    The unique ID for the HMAC credentials for the Object Storage instance.

    --hmac-key HMAC_KEY
    The HMAC key for the Object Storage instance.

    --type LOG_TYPE
    Optional: The type of logs that we want to create a snapshot of. Currently, master is the default and only option.

    -q
    Optional: Do not show the message of the day or update reminders.

Example command:

    ibmcloud oc logging collect --cluster mycluster --cos-bucket mybucket --cos-endpoint s3-api.us-geo.objectstorage.softlayer.net --hmac-key-id e2e7f5c9fo0144563c418dlhi3545m86 --hmac-key c485b9b9fo4376722f692b63743e65e1705301ab051em96j



ibmcloud oc logging collect-status

Check the status of the log collection snapshot request for the cluster.

    ibmcloud oc logging collect-status --cluster CLUSTER [--output json]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster that we want to create a snapshot for.

    --output json
    Optional: Prints the command output in JSON format.

Example command:

    ibmcloud oc logging collect-status --cluster mycluster



ibmcloud oc logging config create

Create a logging configuration. We can use this command to forward logs for containers, applications, worker nodes, OpenShift clusters, and Ingress application load balancers to an external syslog server.

    ibmcloud oc logging config create --cluster CLUSTER --logsource LOG_SOURCE --type syslog [--namespace KUBERNETES_NAMESPACE] [--hostname LOG_SERVER_HOSTNAME_OR_IP] [--port LOG_SERVER_PORT] [--space CLUSTER_SPACE] [--org CLUSTER_ORG] [--app-containers CONTAINERS] [--app-paths PATHS_TO_LOGS] [--syslog-protocol PROTOCOL] [--skip-validation] [--force-update] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster

Command options:

    -c, --cluster CLUSTER
    The name or ID of the cluster.

    --logsource LOG_SOURCE
    The log source to enable log forwarding for. This argument supports a comma-separated list of log sources to apply for the configuration. Accepted values are container, application, worker, kubernetes, storage, and ingress. If you do not provide a log source, configurations are created for container and ingress.

    --type syslog
    Enter syslog to forward logs to an external server.

    -n, --namespace KUBERNETES_NAMESPACE
    The OpenShift project that we want to forward logs from. Log forwarding is not supported for the ibm-system and kube-system OpenShift projects. This value is valid only for the container log source and is optional. If you do not specify a project, then all projects in the cluster use this configuration.

    --hostname LOG_SERVER_HOSTNAME
    The hostname or IP address of the log collector server.

    --port LOG_SERVER_PORT
    Optional: The port of the log collector server. If you do not specify a port, then the standard port 514 is used for syslog and the standard port 9091 is used for ibm.

    --space CLUSTER_SPACE
    Optional: The name of the Cloud Foundry space that we want to send logs to. This value is valid only for log type ibm and is optional. If you do not specify a space, logs are sent to the account level. If you do, we must also specify an org.

    --org CLUSTER_ORG
    Optional: The name of the Cloud Foundry org that the space is in. This value is valid only for log type ibm and is required if you specified a space.

    -p, --app-path
    The path on the container that the apps are logging to. To forward logs with source type application, we must provide a path. Wildcards, such as '/var/log/.log', can be used, but recursive globs, such as '/var/log/*/test.log', cannot be used. To specify more than one path, use multiple flags, such as -p /var/log/myApp1/&ast; -p /var/log/myApp2/&ast;. This value is required for log source application.

    --syslog-protocol
    The transfer layer protocol that is used when the logging type is syslog. Supported values are tcp, tls, and the default udp. When forwarding to a rsyslog server with the udp protocol, logs that are over 1 KB are truncated.

    -C, --app-container
    To forward logs from apps, we can specify the name of the container that contains the app. To specify more than one container, use multiple flags, such as -C /var/log/myApp1/&ast; -C /var/log/myApp2/&ast;. If no containers are specified, logs are forwarded from all of the containers that contain the paths that you provided. This option is only valid for log source application.

    --skip-validation
    Optional: Skip validation of the org and space names when they are specified. Skipping validation decreases processing time, but an invalid logging configuration does not correctly forward logs.

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Examples:

Example for log type syslog that forwards from a container log source on default port 514:

    ibmcloud oc logging config create my_cluster --logsource container --namespace my_namespace --hostname 169.xx.xxx.xxx --type syslog

Example for log type syslog that forwards logs from an ingress source on a port different than the default:

    ibmcloud oc logging config create --cluster my_cluster --logsource container --hostname 169.xx.xxx.xxx --port 5514 --type syslog



ibmcloud oc logging config get

View all log forwarding configurations for a cluster, or filter logging configurations based on log source.

    ibmcloud oc logging config get --cluster CLUSTER [--logsource LOG_SOURCE] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --logsource LOG_SOURCE
    Optional: The kind of log source for which we want to filter. Logging configurations of only this log source in the cluster are returned. Accepted values are container, storage, application, worker, kubernetes, and ingress.

    --show-covering-filters
    Shows the logging filters that render previous filters obsolete.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc logging config get --cluster my_cluster --logsource worker



ibmcloud oc logging config rm

Delete one log forwarding configuration or all logging configurations for a cluster. Deleting the log configuration stops log forwarding to a remote syslog server.

    ibmcloud oc logging config rm --cluster CLUSTER (--namespace NAMESPACE --id LOG_CONFIG_ID] [--all] [--force-update] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    -n, --namespace NAMESPACE
    The project we want to remove the log forwarding configuration from. If there is more than one config for the same project, use the --id <logging_configuration_ID> flag instead.

    --id LOG_CONFIG_ID
    To remove a single logging configuration, the logging configuration ID.

    --all
    The flag to remove all logging configurations in a cluster.

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc logging config rm --cluster my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e



ibmcloud oc logging config update

Update the details of a log forwarding configuration.

    ibmcloud oc logging config update --cluster CLUSTER --id LOG_CONFIG_ID --type LOG_TYPE [--namespace NAMESPACE] [--hostname LOG_SERVER_HOSTNAME_OR_IP] [--port LOG_SERVER_PORT] [--space CLUSTER_SPACE] [--org CLUSTER_ORG] [--app-paths PATH] [--app-containers PATH] [--output json] [--skipValidation] [--force-update] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --id LOG_CONFIG_ID
    Required: The logging configuration ID that we want to update.

    --type LOG_TYPE
    Required: The log forwarding protocol that we want to use. Currently, syslog and ibm are supported.

    -n, --namespace NAMESPACE
    The OpenShift project that we want to forward logs from. Log forwarding is not supported for the ibm-system and kube-system OpenShift projects. This value is valid only for the container log source. If you do not specify a project, then all projects in the cluster use this configuration.

    --hostname LOG_SERVER_HOSTNAME
    The hostname or IP address of the log collector server.

    --port LOG_SERVER_PORT
    The port of the log collector server. This value is optional when the logging type is syslog. If you do not specify a port, then the standard port 514 is used for syslog and 9091 is used for ibm.

    --space CLUSTER_SPACE
    Optional: The name of the space that we want to send logs to. This value is valid only for log type ibm and is optional. If you do not specify a space, logs are sent to the account level. If you do, we must also specify an org.

    --org CLUSTER_ORG
    Optional: The name of the Cloud Foundry org that the space is in. This value is valid only for log type ibm and is required if you specified a space.

    -p, --app-path
    The path on the container that the apps are logging to. To forward logs with source type application, we must provide a path. Wildcards, such as '/var/log/.log', can be used, but recursive globs, such as '/var/log/*/test.log', cannot be used. To specify more than one path, use multiple flags, such as -p /var/log/myApp1/&ast; -p /var/log/myApp2/&ast;. This value is required for log source application.

    -C, --app-container
    To forward logs from apps, we can specify the name of the container that contains the app. To specify more than one container, use multiple flags, such as -C /var/log/myApp1/&ast; -C /var/log/myApp2/&ast;. If no containers are specified, logs are forwarded from all of the containers that contain the paths that you provided. This option is only valid for log source application.

    --output json
    Optional: Prints the command output in JSON format.

    --skipValidation
    Optional: Skip validation of the org and space names when they are specified. Skipping validation decreases processing time, but an invalid logging configuration does not correctly forward logs.

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    -q
    Optional: Do not show the message of the day or update reminders.

Example for log type ibm:

    ibmcloud oc logging config update --cluster my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e --type ibm

Example for log type syslog:

    ibmcloud oc logging config update --cluster my_cluster --id f4bc77c0-ee7d-422d-aabf-a4e6b977264e --hostname localhost --port 5514 --type syslog



ibmcloud oc logging filter create

Filter out logs that are forwarded by your logging configuration.

    ibmcloud oc logging filter create --cluster CLUSTER --type LOG_TYPE [--logging-config CONFIG] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--message MESSAGE] [--regex-message MESSAGE] [--force-update] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster to create a logging filter for.

    --type LOG_TYPE
    The type of logs that we want to apply the filter to. Currently all, container, and host are supported.

    -lc, --logging-config CONFIG
    Optional: The logging configuration ID. If not provided, the filter is applied to all of the cluster logging configurations that are passed to the filter. We can view log configurations that match the filter by using the --show-matching-configs flag with the command. To specify multiple IDs, use multiple flags, such as -lc id1 -lc id2.

    -n, --namespace KUBERNETES_NAMESPACE
    Optional: The OpenShift project from which we want to filter logs.

    --container CONTAINER_NAME
    Optional: The name of the container from which we want to filter out logs. This flag applies only when we are using log type container.

    --level LOGGING_LEVEL
    Optional: Filters out logs that are at the specified level and less. Acceptable values in their canonical order are fatal, error, warn/warning, info, debug, and trace. As an example, if you filtered logs at the info level, debug, and trace are also filtered. Note: We can use this flag only when log messages are in JSON format and contain a level field. Example output: {"log": "hello", "level": "info"}

    --message MESSAGE
    Optional: Filters out any logs that contain a specified message anywhere in the log. Example: The messages "Hello", "!", and "Hello, World!", would apply to the log "Hello, World!".

    --regex-message MESSAGE
    Optional: Filters out any logs that contain a specified message that is written as a regular expression anywhere in the log. Example: The pattern "hello [0-9]" would apply to "hello 1", "hello 2", and "hello 9".

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Examples:

This example filters out all logs that are forwarded from containers with the name test-container in the default project that are at the debug level or less, and have a log message that contains "GET request".

    ibmcloud oc logging filter create --cluster example-cluster --type container --namespace default --container test-container --level debug --message "GET request"

This example filters out all of the logs that are forwarded, at an info level or less, from a specific cluster. The output is returned as JSON.

    ibmcloud oc logging filter create --cluster example-cluster --type all --level info --output json



ibmcloud oc logging filter get

View a logging filter configuration.

    ibmcloud oc logging filter get --cluster CLUSTER [--id FILTER_ID] [--show-matching-configs] [--show-covering-filters] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster that we want to view filters from.

    --id FILTER_ID
    The ID of the log filter that we want to view.

    --show-matching-configs
    Optional: Show the logging configurations that match the configuration that you're viewing.

    --show-covering-filters
    Optional: Show the logging filters that render previous filters obsolete.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc logging filter get --cluster mycluster --id 885732 --show-matching-configs



ibmcloud oc logging filter rm

Delete a logging filter.

    ibmcloud oc logging filter rm --cluster CLUSTER [--id FILTER_ID] [--all] [--force-update] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    The name or ID of the cluster that we want to delete a filter from.

    --id FILTER_ID
    The ID of the log filter to delete.

    --all
    Optional: Delete all of our log forwarding filters.

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc logging filter rm --cluster mycluster --id 885732



ibmcloud oc logging filter update

Update a logging filter.

    ibmcloud oc logging filter update --cluster CLUSTER --id FILTER_ID --type LOG_TYPE [--logging-config CONFIG] [--namespace KUBERNETES_NAMESPACE] [--container CONTAINER_NAME] [--level LOGGING_LEVEL] [--message MESSAGE] [--regex-message MESSAGE] [--force-update] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster that we want to update a logging filter for.

    --id FILTER_ID
    The ID of the log filter to update.

    --type LOG_TYPE
    The type of logs that we want to apply the filter to. Currently all, container, and host are supported.

    -lc, --logging-config CONFIG
    Optional: The logging configuration ID. If not provided, the filter is applied to all of the cluster logging configurations that are passed to the filter. We can view log configurations that match the filter by using the --show-matching-configs flag with the command. To specify multiple IDs, use multiple flags, such as -lc id1 -lc id2.

    -n, --namespace KUBERNETES_NAMESPACE
    Optional: The OpenShift project from which we want to filter logs.

    --container CONTAINER_NAME
    Optional: The name of the container from which we want to filter out logs. This flag applies only when we are using log type container.

    --level LOGGING_LEVEL
    Optional: Filters out logs that are at the specified level and less. Acceptable values in their canonical order are fatal, error, warn/warning, info, debug, and trace. As an example, if you filtered logs at the info level, debug, and trace are also filtered. Note: We can use this flag only when log messages are in JSON format and contain a level field. Example output: {"log": "hello", "level": "info"}

    --message MESSAGE
    Optional: Filters out any logs that contain a specified message anywhere in the log. Example: The messages "Hello", "!", and "Hello, World!", would apply to the log "Hello, World!".

    --regex-message MESSAGE
    Optional: Filters out any logs that contain a specified message that is written as a regular expression anywhere in the log. Example: The pattern "hello [0-9]" would apply to "hello 1", "hello 2", and "hello 9"

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Examples:

This example filters out all logs that are forwarded from containers with the name test-container in the default project that are at the debug level or less, and have a log message that contains "GET request".

    ibmcloud oc logging filter update --cluster example-cluster --id 885274 --type container --namespace default --container test-container --level debug --message "GET request"

This example filters out all of the logs that are forwarded, at an info level or less, from a specific cluster. The output is returned as JSON.

    ibmcloud oc logging filter update --cluster example-cluster --id 274885 --type all --level info --output json



ibmcloud oc logging refresh

Refresh the logging configuration for the cluster. This action refreshes the logging token for any logging configuration that is forwarding to the space level in the cluster.

The logging config refresh alias for this command is deprecated.

    ibmcloud oc logging refresh --cluster CLUSTER [--force-update] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --force-update
    Force your Fluentd pods to update to the latest version. Fluentd must be at the latest version to change your logging configurations.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc logging refresh --cluster my_cluster



nlb-dns commands

Create and manage subdomains for network load balancer (NLB) IP addresses and health check monitors for subdomains. For more information, see Registering a load balancer subdomain.


ibmcloud oc nlb-dns add

Add one or more network load balancer (NLB) IP addresses to an existing subdomain that you created with the ibmcloud oc nlb-dns create classic command.

For example, in a multizone cluster, we might create an NLB in each zone to expose an app. You register the NLB IPs with a subdomain by running ibmcloud oc nlb-dns create classic. Later, you add another zone to the cluster and another NLB for that zone. We can use this command to add the new NLB IP to this existing subdomain. When a user accesses the app subdomain, the client accesses one of these IPs at random, and the request is sent to that NLB.

    ibmcloud oc nlb-dns add --cluster CLUSTER --ip NLB_IP [--ip NLB2_IP2 --ip NLB3_IP ...] --nlb-host SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --ip NLB_IP
    The NLB IP address(es) that we want to add to the subdomain. To see your NLB IPs, run oc get svc. To specify multiple IP addresses, use multiple --ip flags.

    --nlb-host SUBDOMAIN
    The subdomain that we want to add IPs to. To see existing subdomains, run ibmcloud oc nlb-dns ls.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns add --cluster mycluster --ip 1.1.1.1 --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns create classic

Publicly expose the app by creating a DNS subdomain to register a network load balancer (NLB) IP.

    ibmcloud oc nlb-dns create classic --cluster CLUSTER --ip NLB_IP [--ip NLB2_IP --ip NLB3_IP ...] [--secret-namespace NAMESPACE] [--type public] [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --ip IP
    The network load balancer IP address that we want to register. To see your NLB IP addresses, run oc get svc. To specify multiple IP addresses, use multiple --ip flags.

    --secret-namespace NAMESPACE
    The OpenShift project where we want to create the Kubernetes secret that holds the SSL certificate information for the NLB. If you do not specify a project, the secret is automatically created in the default project.

    --type public
    The subdomain type. Currently, only public is supported.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns create classic --cluster mycluster --ip 1.1.1.1



ibmcloud oc nlb-dns create vpc-gen2

Create a DNS entry for a VPC Gen 2 load balancer hostname.

When you create a VPC load balancer, the load balancer is assigned a hostname instead of an external IP address. Additionally, a default public VPC load balancer provides a hostname for all public router services in the cluster, and a default private VPC load balancer provides a hostname for all private router services in the cluster. If you created a VPC load balancer, we can use this hostname to access the app directly. If you use Ingress, we can specify this hostname in your Ingress resource files to register the app with Ingress.

However, this VPC load balancer hostname does not support TLS termination. If we want an SSL certificate for the app domain, we can use the ibmcloud oc nlb-dns create vpc-gen2 command to create a DNS subdomain for the VPC load balancer hostname. IBM Cloud takes care of generating and maintaining the wildcard SSL certificate for the subdomain for you. Note that in VPC clusters, we can create subdomains for both public and private VPC load balancers.

We can also use this command to create a DNS entry for the hostname for the private ALBs.

    ibmcloud oc nlb-dns create vpc-gen2 --cluster CLUSTER --lb-host VPC_LB_HOSTNAME [--secret-namespace NAMESPACE] [--type (public|private)] [--output json] [-q]

Supported infrastructure provider: VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --lb-host VPC_LB_HOSTNAME
    The VPC load balancer hostname. To see VPC load balancer hostnames, run oc get svc -o wide.

    --secret-namespace NAMESPACE
    The OpenShift project where we want to create the Kubernetes secret that holds the SSL certificate information for the NLB. If you do not specify a project, the secret is automatically created in the default project.

    --type (public|private)
    The subdomain type: public or private.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns create vpc-gen2 --cluster mycluster --lb-host 1234abcd-us-south.lb.appdomain.cloud



ibmcloud oc nlb-dns ls

In a classic cluster, list the network load balancer (NLB) IP addresses that are registered to DNS subdomains. In a VPC cluster, list the VPC load balancer hostnames that are registered to DNS subdomains.

    ibmcloud oc nlb-dns ls --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns ls --cluster mycluster



ibmcloud oc nlb-dns monitor configure

Configure and optionally enable a health check monitor for an existing NLB subdomain in a cluster. When you enable a monitor for the subdomain, the monitor health checks the NLB IP in each zone and keeps the DNS lookup results updated based on these health checks.

We can use this command to create and enable a health check monitor, or to update the settings for an existing health check monitor. To create a new monitor, include the --enable flag and the flags for all settings that we want to configure.

To update an existing monitor, we must include all the flags for the settings that we want, including existing settings.

    ibmcloud oc nlb-dns monitor configure --cluster CLUSTER --nlb-host SUBDOMAIN [--enable] [--description DESCRIPTION] [--type TYPE] [--method METHOD] [--path PATH] [--timeout TIMEOUT] [--retries RETRIES] [--interval INTERVAL] [--port PORT] [--header HEADER] [--expected-body BODY STRING] [--expected-codes HTTP CODES] [--follows-redirects TRUE] [--allows-insecure TRUE] [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    The name or ID of the cluster where the subdomain is registered.

    --nlb-host SUBDOMAIN
    The subdomain to configure a health check monitor for. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --enable
    Include this flag to enable a new health check monitor for a subdomain.

    --description DESCRIPTION
    A description of the health monitor.

    --type TYPE
    The protocol to use for the health check: HTTP, HTTPS, or TCP. Default: HTTP

    --method METHOD
    The method to use for the health check. Default for type HTTP and HTTPS: GET. Default for type TCP: connection_established.

    --path PATH
    When type is HTTPS: The endpoint path to health check against. Default: /

    --timeout TIMEOUT
    The timeout, in seconds, before the IP is considered unreachable. The health check waits the number of seconds specified in the interval parameter before trying to reach the IP again. The value must be an integer in the range 1 - 15. Default: 5

    --retries RETRIES
    When a timeout occurs, the number of retries to attempt before the unreachable IP is considered unhealthy. Retries are attempted immediately. The value must be an integer in the range 1 - 5. Default: 2

    --interval INTERVAL
    The interval, in seconds, between each health check. Short intervals might improve failover time, but increase load on the IPs. The value must be an integer in the range 10 - 3600 and must be greater than (RETRIES + 1) * TIMEOUT. Default: 60

    --port PORT
    The port number to connect to for the health check. When type is TCP, this parameter is required. When type is HTTP or HTTPS, define the port only if you use a port other than 80 for HTTP or 443 for HTTPS. Default for TCP: 0. Default for HTTP: 80. Default for HTTPS: 443.

    --header HEADER
    Required when type is HTTP or HTTPS: HTTP request headers to send in the health check, such as a Host header. The User-Agent header cannot be overridden. This flag is valid only for type 'HTTP' or 'HTTPS'. To add more than one header to the requests, specify this flag multiple times. This flag accepts values in the following format: '--header Header-Name=value'. When updating a monitor, the existing headers are replaced by the ones you specify. To delete all existing headers specify the flag with an empty value '--header ""'.

    --expected-body BODY STRING
    When type is HTTP or HTTPS: A case-insensitive substring that the health check looks for in the response body. If this string is not found, the IP is considered unhealthy.

    --expected-codes HTTP CODES
    When type is HTTP or HTTPS: HTTP codes that the health check looks for in the response. If the HTTP code is not found, the IP is considered unhealthy. Default: 2xx

    --allows-insecure TRUE
    When type is HTTP or HTTPS: Set to true to not validate the certificate.

    --follows-redirects TRUE
    When type is HTTP or HTTPS: Set to true to follow any redirects that are returned by the IP.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor configure --cluster mycluster --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud --enable --description "Login page monitor" --type HTTPS --method GET --path / --timeout 5 --retries 2 --interval 60 --expected-body "healthy" --expected-codes 2xx --follows-redirects true



ibmcloud oc nlb-dns monitor disable

Disable an existing health check monitor for a subdomain in a cluster.

    ibmcloud oc nlb-dns monitor disable --cluster CLUSTER --nlb-host SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-host SUBDOMAIN
    The subdomain that the monitor health checks. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor disable --cluster mycluster --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns monitor enable

Enable a health check monitor that you configured.

The first time that you create a health check monitor, we must configure and enable it with the ibmcloud oc nlb-dns monitor configure command. Use the ibmcloud oc nlb-dns monitor enable command only to enable a monitor that you configured but did not yet enable, or to re-enable a monitor that you previously disabled.

    ibmcloud oc nlb-dns monitor enable --cluster CLUSTER --nlb-host SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-host SUBDOMAIN
    The subdomain that the monitor health checks. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor enable --cluster mycluster --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns monitor get

View the settings for an existing health check monitor.

    ibmcloud oc nlb-dns monitor get --cluster CLUSTER --nlb-host SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-host SUBDOMAIN
    The subdomain that the monitor health checks. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor get --cluster mycluster --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns monitor ls

List the health check monitor settings for each NLB subdomain in a cluster.

    ibmcloud oc nlb-dns monitor ls --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor ls --cluster mycluster



ibmcloud oc nlb-dns monitor status

List the health check status for the IPs behind NLB subdomains in a cluster.

    ibmcloud oc nlb-dns monitor status --cluster CLUSTER [--nlb-host SUBDOMAIN] [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-host SUBDOMAIN
    Include this flag to view the status for only one subdomain. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns monitor status --cluster mycluster



ibmcloud oc nlb-dns replace

Replace the load balancer hostname that is registered with a DNS subdomain. For example, if you create a new VPC load balancer for the app, but you do not want to create a new DNS subdomain through which users can access the app, we can replace the hostname of the old load balancer with the hostname of the new load balancer.

    ibmcloud oc nlb-dns replace --cluster CLUSTER --lb-host NEW_LB_HOSTNAME --nlb-subdomain SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: VPC Generation 1 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --lb-host NEW_LB_HOSTNAME
    The hostname of the new VPC load balancer to update the subdomain with. To see VPC load balancer hostnames, run oc get svc -o wide.

    nlb-subdomain SUBDOMAIN
    The DNS subdomain that we want to replace the load balancer hostname for. To see existing subdomains, run ibmcloud oc nlb-dns ls --cluster <cluster>.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns replace --cluster mycluster --lb-host 1234abcd-us-south.lb.appdomain.cloud nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns rm classic

Remove a network load balancer (NLB) IP address from a subdomain. If you remove all IPs from a subdomain, the subdomain still exists but no IPs are associated with it. Note: You must run this command for each IP address that we want to remove.

    ibmcloud oc nlb-dns rm classic --cluster CLUSTER --ip IP --nlb-host SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --ip IP
    The NLB IP that we want to remove. To see the IPs registered with each subdomain, run ibmcloud oc nlb-dns ls --cluster <cluster>.

    --nlb-host SUBDOMAIN
    The subdomain that we want to remove an IP from. To see existing subdomains, run ibmcloud oc nlb-dns ls.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns rm classic --cluster mycluster --ip 1.1.1.1 --nlb-host mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



ibmcloud oc nlb-dns rm vpc-gen2

Remove the VPC Gen 2 load balancer hostname that is registered with a DNS subdomain. After you remove the hostname, the DNS subdomain still exists, but no VPC load balancer is registered with it.

    ibmcloud oc nlb-dns rm vpc-gen2 --cluster CLUSTER --nlb-subdomain SUBDOMAIN [--output json] [-q]

Supported infrastructure provider: VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-subdomain SUBDOMAIN
    The subdomain that we want to disassociate from the VPC load balancer hostname. To see existing subdomains, run ibmcloud oc nlb-dns ls --cluster <cluster>.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns rm vpc-gen2 --cluster mycluster --nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



Experimental: ibmcloud oc nlb-dns secret regenerate

Regenerate the certificate and secret for an NLB subdomain.

If the Let’s Encrypt certificate creation fails during secret regeneration, a 10 minute wait period must pass before the regeneration is automatically attempted again. The regeneration of the secret takes another 5 minutes to complete, making it a total of 15 minutes before the process is completed.

To avoid the Let’s Encrypt rate limit, do not regenerate a secret more than 5 times per day.

    ibmcloud oc nlb-dns secret regenerate --cluster CLUSTER --nlb-subdomain SUBDOMAIN [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-subdomain SUBDOMAIN
    The subdomain to regenerate the secret for. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns secret regenerate --cluster mycluster --nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud



Experimental: ibmcloud oc nlb-dns secret rm

Delete a secret from an NLB subdomain and prevent future renewal of the certificate.

We might delete the secret for an NLB subdomain if you no longer use the subdomain, or if the owner of the secret leaves your organization.

    ibmcloud oc nlb-dns secret rm --cluster CLUSTER --nlb-subdomain SUBDOMAIN [-f] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --nlb-subdomain SUBDOMAIN
    The subdomain to delete the secret for. To list subdomains, run ibmcloud oc nlb-dns ls --cluster CLUSTER.

    -f
    Optional: Force the command to run with no user prompts.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc nlb-dns secret rm --cluster mycluster --nlb-subdomain mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud




webhook-create command

Register a webhook.

    ibmcloud oc webhook-create --cluster CLUSTER --level LEVEL --type slack --url URL [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --level LEVEL
    Optional: The notification level, such as Normal or Warning. Warning is the default value.

    --type slack
    Required: The webhook type. Currently, Slack is supported.

    --url URL
    Required: The URL for the webhook.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc webhook-create --cluster my_cluster --level Normal --type slack --url http://github.com/mywebhook



api-key commands

View information about the API key for a cluster or reset it to a new key.


ibmcloud oc api-key info

View the name and email address for the owner of the IBM Cloud Identity and Access Management (IAM) API key that Red Hat OpenShift on IBM Cloud uses to authenticate certain requests like infrastructure in the region and resource group. For more information, see Accessing the portfolio with the API key.

To create a different API key for the resource group and region, use the ibmcloud oc api-key reset command.

If you manually set IBM Cloud infrastructure credentials by using the ibmcloud oc credential set command, the API key that is returned in this command is not used for infrastructure permissions.

    ibmcloud oc api-key info --cluster CLUSTER [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    -c, --cluster CLUSTER
    Required: The name or ID of the cluster.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc api-key info --cluster my_cluster



ibmcloud oc api-key reset

Create an IBM Cloud IAM API key that impersonates the user's permissions to authenticate requests for all clusters in the current resource group and region. For more information, see Accessing the portfolio with the API key.

Before you use this command, make sure that the user who runs this command has the required IBM Cloud Kubernetes Service and IBM Cloud infrastructure permissions. Target the resource group and region that we want to set the API key for.

When the API key is reset, the previous API key that was used, if any, for the region and resource group is deleted. Before you reset the API key, check whether we have other services that use the existing API key, such as a key management service (KMS) provider or the default IBM Cloud Certificate Manager service instance for the cluster.

    ibmcloud oc api-key reset --region REGION [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --region REGION
    Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc api-key reset --region us-south



credential commands

Set and unset credentials that allow us to access the classic IBM Cloud infrastructure portfolio through your IBM Cloud account.

We can manually set infrastructure credentials to a different account only for classic clusters, not for VPC clusters.


ibmcloud oc credential get

If you set up your IBM Cloud account to use different credentials to access the IBM Cloud infrastructure portfolio, get the infrastructure username for the region and resource group that we are currently targeted to.

    ibmcloud oc credential get --region REGION [-q] [--output json]

Supported infrastructure provider: Classic

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --region REGION
    Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc credential get --region us-south



ibmcloud oc credential set classic

Set credentials for a resource group and region so that we can access the IBM Cloud infrastructure portfolio through your IBM Cloud account.

If we have an IBM Cloud Pay-As-You-Go account, we have access to the IBM Cloud infrastructure portfolio by default. However, we might want to use a different, existing IBM Cloud infrastructure account to order infrastructure. We can link this infrastructure account to your IBM Cloud account by using this command.

If IBM Cloud infrastructure credentials are manually set for a region and a resource group, these credentials are used to order infrastructure for all clusters within that region in the resource group. These credentials are used to determine infrastructure permissions, even if an IBM Cloud IAM API key exists for the resource group and region. If the user whose credentials are stored does not have the required permissions to order infrastructure, then infrastructure-related actions, such as creating a cluster or reloading a worker node can fail.

We cannot set multiple credentials for the same IBM Cloud Kubernetes Service resource group and region.

Before you use this command, make sure that the user whose credentials are used has the required IBM Cloud Kubernetes Service and IBM Cloud infrastructure permissions.

    ibmcloud oc credential set classic --infrastructure-api-key API_KEY --infrastructure-username USERNAME [--region REGION] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --infrastructure-username USERNAME
    Required: IBM Cloud infrastructure account API username. The infrastructure API username is not the same as the IBMid. To view the infrastructure API username, see Manage classic infrastructure API keys.

    --infrastructure-api-key API_KEY
    Required: IBM Cloud infrastructure account API key. To view or generate an infrastructure API key, see Manage classic infrastructure API keys.

    --region REGION
    Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc credential set classic --infrastructure-api-key <api_key> --infrastructure-username dbmanager --region us-south



ibmcloud oc credential unset

Remove the credentials for a resource group and region to remove access to the IBM Cloud infrastructure portfolio through your IBM Cloud account.

After you remove the credentials, the IBM Cloud IAM API key is used to order resources in IBM Cloud infrastructure.

    ibmcloud oc credential unset --region REGION [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --region REGION
    Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc credential unset --region us-south



infra-permissions commands

Check classic IBM Cloud infrastructure permissions that are used in Red Hat OpenShift on IBM Cloud.

The ibmcloud oc infra-permissions commands check only classic IBM Cloud infrastructure, not VPC permissions.


ibmcloud oc infra-permissions get

Check whether the credentials that allow access to the IBM Cloud infrastructure portfolio for the targeted resource group and region are missing suggested or required infrastructure permissions.

What do required and suggested infrastructure permissions mean?
If the infrastructure credentials for the region and resource group are missing any permissions, the output of this command returns a list of required and suggested permissions.

  • Required: These permissions are needed to successfully order and manage infrastructure resources such as worker nodes. If the infrastructure credentials are missing one of these permissions, common actions such as worker reload can fail for all clusters in the region and resource group.
  • Suggested: These permissions are helpful to include in your infrastructure permissions, and might be necessary in certain use cases. For example, the Add Compute with Public Network Port infrastructure permission is suggested because if we want public networking, we need this permission. However, if your use case is a cluster on the private VLAN only, the permission is not needed so it is not considered required.

For a list of common use cases by permission, see Infrastructure roles.

What if I see an infrastructure permission that I can't find in the console or Infrastructure roles table?
Support Case permissions are managed in a different part of the console than infrastructure permissions. See step 8 of Customizing infrastructure permissions.

Which infrastructure permissions do I assign?
If your company's policies for permissions are strict, we might need to limit the suggested permissions for the cluster's use case. Otherwise, make sure that your infrastructure credentials for the region and resource group include all the required and suggested permissions.

For most use cases, set up the API key for the region and resource group with the appropriate infrastructure permissions. For to use another infrastructure account that differs from your current account, set up manual credentials.

How do I control what actions the users can perform?
After infrastructure credentials are set up, we can control what actions your users can perform by assigning them IBM Cloud IAM platform roles.

    ibmcloud oc infra-permissions get --region REGION [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --region REGION
    Required: Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc infra-permissions get --region us-south

Example output:

    Missing Virtual Worker Permissions Add Server suggested Cancel Server suggested View Virtual Server Details required Missing Physical Worker Permissions No changes are suggested or required. Missing Network Permissions No changes are suggested or required. Missing Storage Permissions Add Storage required Manage Storage required



kms commands

Enable a key management service (KMS) provider in the cluster to encrypt the etcd component and Kubernetes secrets with a root key that you control.


ibmcloud oc kms crk ls

List available customer root keys (CRKs) in a key management service instance. Root keys wrap and unwrap the local data encryption keys (DEKs) that the cluster uses to encrypt its secrets. For more information, see Understand Key Management Service (KMS) providers.

Do not delete root keys in your KMS instance, even if you rotate to use a new key. If you delete a root key that a cluster uses, the cluster becomes unusable, loses all its data, and cannot be recovered.

    ibmcloud oc kms crk ls --instance-id KMS_INSTANCE_ID [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role in IBM Cloud Kubernetes Service

Command options:

    --instance-id KMS_INSTANCE_ID
    The ID of the key management service instance that we want to list root keys for. To list available KMS instances, run ibmcloud oc kms instance ls.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc kms crk ls --instance-id 1aa1a111-1111-1111-a111-a1aaaa1a1a1a


ibmcloud oc kms enable

Encrypt your Kubernetes secrets by enabling a key management service (KMS) provider in the cluster. To rotate a key in a cluster with existing key encryption, rerun this command with a new root key ID.

Do not delete root keys in your KMS instance, even if you rotate to use a new key. If you delete a root key that a cluster uses, the cluster becomes unusable, loses all its data, and cannot be recovered.

    ibmcloud oc kms enable --cluster CLUSTER_NAME_OR_ID --instance-id KMS_INSTANCE_ID --crk ROOT_KEY_ID [--public-endpoint] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Administrator platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --container, -c CLUSTER_NAME_OR_ID
    The name or ID of the cluster.

    --instance-id KMS_INSTANCE_ID
    The ID of the KMS instance that we want to use to encrypt the secrets in the cluster. To list available KMS instances, run ibmcloud oc kms instance ls.

    --crk ROOT_KEY_ID
    The ID of the customer root key (CRK) in your KMS instance that we want to use to wrap the data encryption keys (DEK) that are stored locally in the cluster. To list available root keys, run ibmcloud oc kms crk ls --instance-id <kms_instance_id>.

    --public-endpoint
    Optional: Specify this option to use the KMS public service endpoint. If you do not include this flag, the private service endpoint is used by default.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc kms enable -c mycluster --instance-id a11aa11a-bbb2-3333-d444-e5e555e5ee5 --crk 1a111a1a-bb22-3c3c-4d44-55e555e55e55


ibmcloud oc kms instance ls

List available key management service (KMS) instances in your IBM Cloud account that we can choose to enable in the cluster.

    ibmcloud oc kms instance ls [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role in IBM Cloud Kubernetes Service

Command options:

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc kms instance ls



quota commands


ibmcloud oc quota ls

List all quota and limits for cluster-related resources in your IBM Cloud account.

    ibmcloud oc quota ls [--provider PROVIDER] [--output json]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --provider (classic | vpc-gen2)
    The infrastructure provider type to list quota and limits for.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc quota ls




subnets command

List available subnets in your IBM Cloud infrastructure account.

    ibmcloud oc subnets [--provider (classic | vpc-gen2)] [--vpc-id <VPC_ID> --zone <VPC_ZONE>] [--location LOCATION] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --provider (classic | vpc-gen2)
    The infrastructure provider type to list subnets for. This flag is required to list VPC subnets.

    --vpc-id VPC_ID
    The ID of the VPC to list subnets for. This flag is required when you specify the vpc-classic provider type. To list VPC IDs, run ibmcloud oc vpcs.

    --zone VPC_ZONE
    The zone to list VPC subnets for. This flag is required when you specify a VPC provider type.

    -l, --location LOCATION
    Filter output by a specific location. To see supported locations, run ibmcloud oc locations. To specify multiple locations, use one flag for each location, such as -l dal -l seo.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc subnets -l ams03 -l wdc -l ap



vlan commands

List public and private VLANs for a zone and view the VLAN spanning status.

This group of commands is for classic clusters only.


ibmcloud oc vlan ls

List the public and private VLANs that are available for a zone in your classic IBM Cloud infrastructure account. To list available VLANs, we must have a paid account.

    ibmcloud oc vlan ls --zone ZONE [--all] [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions:

  • To view the VLANs that the cluster is connected to in a zone: Viewer platform role for the cluster in IBM Cloud Kubernetes Service
  • To list all available VLANs in a zone: Viewer platform role for the region in IBM Cloud Kubernetes Service

Command options:

    --zone ZONE
    Required: Enter the zone where we want to list your private and public VLANs. To see available zones, run ibmcloud oc zone ls.

    --all
    Lists all available VLANs. By default VLANs are filtered to show only those VLANs that are valid. To be valid, a VLAN must be associated with infrastructure that can host a worker with local disk storage.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc vlan ls --zone dal10



ibmcloud oc vlan spanning get

View the VLAN spanning status for an IBM Cloud infrastructure account. VLAN spanning enables all devices on an account to communicate with each other through the private network, regardless of its assigned VLAN.

The VLAN spanning option is disabled for clusters that are created in a VRF-enabled account. When VRF is enabled, all VLANs in the account can automatically communicate with each other over the private network. To check whether a VRF is enabled, use the ibmcloud account show command. For more information, see Plan the cluster network setup: Worker-to-worker communication.

    ibmcloud oc vlan spanning get --region REGION [--output json] [-q]

Supported infrastructure provider: Classic

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

Command options:

    --region REGION
    Specify a region in Red Hat OpenShift on IBM Cloud: jp-tok, au-syd, eu-de, eu-gb, us-east, or us-south.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc vlan spanning get --region us-south



vpcs command

List all VPCs in the targeted resource group. If no resource group is targeted, then all VPCs in the account are listed.

    ibmcloud oc vpcs [--provider vpc-gen2] [--output json] [-q]

Supported infrastructure provider:

  • VPC Generation 2 compute

Minimum required permissions:

  • Viewer platform role for IBM Cloud Kubernetes Service

Command options:

    --provider vpc-gen2
    The infrastructure provider type ID for the VPC worker node machine. vpc-gen2 for VPC Generation 2 compute is supported.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc vpcs



addon-versions command

View a list of supported versions for managed add-ons in IBM Cloud Kubernetes Service.

    ibmcloud oc addon-versions [--addon ADD-ON_NAME] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --addon ADD-ON_NAME
    Optional: Specify an add-on name, such as istio or knative, to filter versions for.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc addon-versions --addon istio



flavors command

View a list of available worker node flavors. Flavors vary by zone.

The machine-types alias for this command is deprecated.

Each flavor includes the amount of virtual CPU, memory, and disk space for each worker node in the cluster. By default, the secondary storage disk directory where all container data is stored, is encrypted with LUKS encryption. If the disable-disk-encrypt option is included during cluster creation, then the host's container runtime data is not encrypted. Learn more about the encryption.

We can provision the worker node as a virtual machine on shared or dedicated hardware, or for classic clusters only, as a physical machine on bare metal. Learn more about your flavor options.

    ibmcloud oc flavors --zone ZONE --provider (classic | vpc-gen2) [--show-storage] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --zone ZONE
    Required: Enter the zone where we want to list available flavors. To see available zones for classic clusters, run ibmcloud oc zone ls. To see available zones for VPC clusters, run ibmcloud oc zone ls --provider vpc-gen2 for Generation 2 compute.

    --provider (classic | vpc-gen2)
    The infrastructure provider for which we want to list available flavors.

    --show-storage
    Optional: Show additional raw disks that are available for SDS worker node flavors. For more information, see Software-defined storage (SDS) machines.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example for classic clusters:

    ibmcloud oc flavors --zone dal10 --provider classic

Example for VPC Generation 2 compute clusters:

    ibmcloud oc flavors --zone us-south-1 --provider vpc-gen2



messages command

View current messages from the IBM Cloud Kubernetes Service CLI plug-in for the IBMid user.

    ibmcloud oc messages

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options: None



locations command

List the locations that are supported by IBM Cloud Kubernetes Service. For more information about the locations that are returned, see IBM Cloud Kubernetes Service locations.

    ibmcloud oc locations [--output json]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --output json
    Optional: Prints the command output in JSON format.



versions command

List all the container platform versions that are available for IBM Cloud Kubernetes Service clusters. Update your cluster master and worker nodes to the default version for the latest, stable capabilities.

The kube-versions alias for this command is deprecated.

    ibmcloud oc versions [--show-version (KUBERNETES|OPENSHIFT)] [--output json] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --show-version (KUBERNETES|OPENSHIFT)
    Show only the versions for the specified container platform. Supported values are kubernetes or openshift.

    --output json
    Optional: Prints the command output in JSON format.

    -q
    Optional: Do not show the message of the day or update reminders.

Example:

    ibmcloud oc versions



api command

Target the API endpoint for IBM Cloud Kubernetes Service. If you do not specify an endpoint, we can view information about the current endpoint that is targeted.

Region-specific endpoints are deprecated. Use the global endpoint instead.

For to list and work with resources from one region only, we can use the ibmcloud oc api command to target a regional endpoint instead of the global endpoint.

  • Dallas (US South, us-south): https://us-south.containers.cloud.ibm.com
  • Frankfurt (EU Central, eu-de): https://eu-de.containers.cloud.ibm.com
  • London (UK South, eu-gb): https://eu-gb.containers.cloud.ibm.com
  • Sydney (AP South, au-syd): https://au-syd.containers.cloud.ibm.com
  • Tokyo (AP North, jp-tok): https://jp-tok.containers.cloud.ibm.com
  • Washington, D.C. (US East, us-east): https://us-east.containers.cloud.ibm.com

To use the global functionality, we can use the ibmcloud oc api command again to target the global endpoint: https://containers.cloud.ibm.com

    ibmcloud oc api --endpoint ENDPOINT [--insecure] [--skip-ssl-validation] [--api-version VALUE] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --endpoint ENDPOINT
    The IBM Cloud Kubernetes Service API endpoint. Note: This endpoint is different than the IBM Cloud endpoints. This value is required to set the API endpoint.

    --insecure
    Allow an insecure HTTP connection. This flag is optional.

    --skip-ssl-validation
    Allow insecure SSL certificates. This flag is optional.

    --api-version VALUE
    Optional: Specify the API version of the service that we want to use.

    -q
    Optional: Do not show the message of the day or update reminders.

Example: View information about the current API endpoint that is targeted.

    ibmcloud oc api

    API Endpoint: https://containers.cloud.ibm.com API Version: v1 Skip SSL Validation: false Region: us-south



init command

Initialize the Red Hat OpenShift on IBM Cloud plug-in or specify the region where we want to create or access OpenShift clusters.

Region-specific endpoints are deprecated. Use the global endpoint instead.

For to list and work with resources from one region only, we can use the ibmcloud oc init command to target a regional endpoint instead of the global endpoint.

  • Dallas (US South, us-south): https://us-south.containers.cloud.ibm.com
  • Frankfurt (EU Central, eu-de): https://eu-de.containers.cloud.ibm.com
  • London (UK South, eu-gb): https://eu-gb.containers.cloud.ibm.com
  • Sydney (AP South, au-syd): https://au-syd.containers.cloud.ibm.com
  • Tokyo (AP North, jp-tok): https://jp-tok.containers.cloud.ibm.com
  • Washington, D.C. (US East, us-east): https://us-east.containers.cloud.ibm.com

To use the global functionality, we can use the ibmcloud oc init command again to target the global endpoint: https://containers.cloud.ibm.com

    ibmcloud oc init [--host HOST] [--insecure] [-p] [-u] [-q]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --host HOST
    Optional: The IBM Cloud Kubernetes Service API endpoint to use.

    --insecure
    Allow an insecure HTTP connection.

    -p
    Your IBM Cloud password.

    -u
    Your IBM Cloud username.

    -q
    Optional: Do not show the message of the day or update reminders.

Examples:

  • Example to target the US South regional endpoint:

      ibmcloud oc init --host https://us-south.containers.cloud.ibm.com

  • Example to target the global endpoint again:

      ibmcloud oc init --host https://containers.cloud.ibm.com



script commands


ibmcloud oc script update

Rewrite scripts that call kubernetes-service commands. Legacy-structured commands are replaced with beta-structured commands. For a list of all changes between the legacy and beta formats, see the comparison table in Using the beta Red Hat OpenShift on IBM Cloud plug-in.

Most command behavior and syntax changes in version 1.0. These changes are not compatible with earlier versions. After you update your scripts, we must continue to use version 1.0 of the plug-in within the script or the environment where the script is run. Do not change the IKS_BETA_VERSION environment variable to a different version.

    ibmcloud oc script update [--in-place] FILE [FILE ...]

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: None

Command options:

    --in-place
    Optional: Rewrite the source file with the updated command structure. If this flag is not specified, we can see a summary of the changes to the script file in STDOUT.

    FILE [FILE ...]
    The file that contains the scripts that we want to update.


To use this command to prepare your automation scripts for the release of version 1.0 of the Red Hat OpenShift on IBM Cloud plug-in:

  1. Run the command on a test script without the --in-place flag.

      ibmcloud oc script update ./mytestscript.sh

  2. Review the proposed changes to the script in the difference that is shown in the terminal STDOUT. Example output:

      --- a/script-test-2 +++ b/script-test-2 @@ -1,5 +1,5 @@ -ibmcloud ks logging-config-get --cluster mycluster -ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-containers app1,app2,app3 --app-paths /var/log/path/ -ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-paths=/var/log/path/,/var/log/other/path/ -ibmcloud ks clusters -s --locations dal09,dal12 --output json -ibmcloud ks subnets --locations sao01 +ibmcloud ks logging config get --cluster mycluster +ibmcloud ks logging config update --cluster mycluster --id myconfig --logsource application --type ibm -C app1 -C app2 -C app3 -p /var/log/path/ +ibmcloud ks logging config update --cluster mycluster --id myconfig --logsource application --type ibm -p /var/log/path/ -p /var/log/other/path/ +ibmcloud ks clusters -s -l dal09 -l dal12 --output json +ibmcloud ks subnets -l sao01

  3. To rewrite the script with the proposed updates, run the command again with the --in-place flag.

      ibmcloud oc script update ./mytestscript.sh --in-place

  4. Search for and address any commands that are flagged in the script with # WARNING messages. For example, some commands are deprecated and do not have a replacement command.
  5. Within the script or the environment where the script is run, set the IKS_BETA_VERSION environment variable to 1.0.

      export IKS_BETA_VERSION=1.0

  6. Test your automation with the updated script. Note that we might incur charges if your automation includes creating clusters.
  7. Update all of our scripts.
  8. Update your CLI plug-in to version 1.0.

      ibmcloud plugin update kubernetes-service



Beta: storage commands

Create, get, list, or remove storage volume attachments.

The storage commands are available in beta.

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute


ibmcloud oc storage attachment create

Attach a storage volume to a worker node in the cluster.

Supported infrastructure provider:

  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage attachment create --cluster CLUSTER_ID --volume VOLUME --worker WORKER [--output json]

Command options:

    --cluster CLUSTER_ID
    Required: Specify the cluster ID. To list available clusters, run ibmcloud oc cluster ls.

    --volume VOLUME
    Required: Specify the volume ID. To list available workers, run ibmcloud oc storage volume ls.

    --worker WORKER
    Required: Specify the worker ID. To list available workers, run ibmcloud oc worker ls.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage attachment create --cluster aa1111aa11aaaaa11aa1 --volume 111111111 --worker kube-aa1111aa11aaaaa11aa1-my_cluster-default-00000110 [--output json]


ibmcloud oc storage attachment get

Get the details of a storage volume attachment in the cluster.

Supported infrastructure provider:

  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage attachment get --cluster CLUSTER_ID --attachment ATTACHMENT --worker WORKER [--output json]

    --cluster CLUSTER_ID
    Required: Specify the cluster ID. To list available clusters, run ibmcloud oc cluster ls.

    --attachment ATTACHMENT
    Required: Specify the volume attachment ID. To list available attachments, run ibmcloud oc storage attachment ls.

    --worker WORKER
    Required: Specify the worker ID. To list available workers, run ibmcloud oc worker ls.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage attachment get --cluster aa1111aa11aaaaa11aa1 --attachment 0111-1a111aaa-1111-1111-111a-aaa1a1a11a11 --worker kube-aa1111aa11aaaaa11aa1-my_cluster-default-00000110 [--output json]


ibmcloud oc storage attachment ls

List the storage volume attachments for a worker node in the cluster.

Supported infrastructure provider:

  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage attachment ls --cluster CLUSTER_ID --worker WORKER [--output json]

    --cluster CLUSTER_ID
    Required: Specify the cluster ID. To list available clusters, run ibmcloud oc cluster ls.

    --worker WORKER
    Required: Specify the worker ID. To list available workers, run ibmcloud oc worker ls.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage attachment ls --cluster aa1111aa11aaaaa11aa1 --worker kube-aa1111aa11aaaaa11aa1-my_cluster-default-00000110 [--output json]


ibmcloud oc storage attachment rm

Remove a storage volume from a worker node in the cluster.

Supported infrastructure provider:

  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage attachment rm --cluster CLUSTER_ID --attachment ATTACHMENT --worker WORKER [--output json]

Command options:

    --cluster CLUSTER_ID
    Required: Specify the cluster ID. To list available clusters, run ibmcloud oc cluster ls.

    --attachment ATTACHMENT
    Required: Specify the volume attachment ID. To list available attachments, run ibmcloud oc storage attachment ls.

    --worker WORKER
    Required: Specify the worker ID. To list available workers, run ibmcloud oc worker ls.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage attachment rm --cluster aa1111aa11aaaaa11aa1 --attachment 0111-1a111aaa-1111-1111-111a-aaa1a1a11a11 --worker kube-aa1111aa11aaaaa11aa1-my_cluster-default-00000110 [--output json]


ibmcloud oc storage volume get

List storage volumes for the classic clusters.

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Viewer platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage volume get --volume VOLUME

Command options:

    --volume VOLUME
    Required: Specify the volume ID. To list available volumes, run ibmcloud ks storage volume ls.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage volume get --volume 111111111


ibmcloud oc storage volume ls

Get a list of storage volumes.

Supported infrastructure provider:

  • Classic
  • VPC Generation 2 compute

Minimum required permissions: Editor platform role for the cluster in IBM Cloud Kubernetes Service

    ibmcloud oc storage volume ls [--cluster CLUSTER_ID] [--provider PROVIDER] [--zone ZONE] [--output json]

Command options:

    --cluster CLUSTER_ID
    Optional: Specify the cluster ID. To list available clusters, run ibmcloud oc cluster ls.

    --provider PROVIDER
    Optional: Specify the provider. Supported values are classic, vpc-classic, and vpc-gen2.

    --zone ZONE
    Optional: Specify the zone. To list available zones, run ibmcloud oc locations.

    --output json
    Optional: Prints the command output in JSON format.

Example:

    ibmcloud oc storage volume ls --cluster aa1111aa11aaaaa11aa1