vania-janet/multiturn-rag-retrieval-data huggingface dataset:
ibmcloud ks worker ls --cluster CLUSTER [--worker-pool POOL] [--show-pools] [--show-deleted] [--output json] [-q]

Minimum required permissions
: Viewer platform access 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 ks 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 worker ls command 

ibmcloud ks worker ls --cluster my_cluster







 ibmcloud ks worker reboot 

Virtual Private Cloud

Classic infrastructure

Reboot a worker node in a cluster.

During the reboot, the state of your worker node does not change. For example, you might use a reboot if the worker node status in classic IBM Cloud infrastructure is Powered Off and you 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 you know that a reboot can help recover your worker node. In all other cases, [reload your worker node](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_worker_reload) instead.
ibmcloud ks worker ls --cluster CLUSTER [--worker-pool POOL] [--show-pools] [--show-deleted] [--output json] [-q]

Minimum required permissions
: Viewer platform access 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 ks 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 worker ls command 

ibmcloud ks worker ls --cluster my_cluster







 ibmcloud ks worker reboot 

Virtual Private Cloud

Classic infrastructure

Reboot a worker node in a cluster.

During the reboot, the state of your worker node does not change. For example, you might use a reboot if the worker node status in classic IBM Cloud infrastructure is Powered Off and you 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 you know that a reboot can help recover your worker node. In all other cases, [reload your worker node](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload) instead.
ibmcloud oc worker ls --cluster CLUSTER [--worker-pool POOL] [--show-pools] [--show-deleted] [--output json] [-q]

Minimum required permissions
: Viewer platform access 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 worker ls command 

ibmcloud oc worker ls --cluster my_cluster







 ibmcloud oc worker reboot 

Virtual Private Cloud

Classic infrastructure

Reboot a worker node in a cluster.

During the reboot, the state of your worker node does not change. For example, you might use a reboot if the worker node status in classic IBM Cloud infrastructure is Powered Off and you 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 you know that a reboot can help recover your worker node. In all other cases, [reload your worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reload) instead.
Example output.

NAME READY STATUS RESTARTS AGE
my-deployment-ccdf87dfb-vzn95 1/1 Running 0 5m27s
8. Get the pods logs to verify the timestamp is written.

kubectl logs

Example output.

2022-01-21 14:18:59



You've successfully created a deployment that uses Block Storage for Classic! For more information, see the following links.



* [Installing the Block Storage for Classic plug-in](https://cloud.ibm.com/docs/containers?topic=containers-block_storageinstall_block)
* [Adding Block Storage for Classic to apps](https://cloud.ibm.com/docs/containers?topic=containers-block_storageadd_block).
* [Storage class reference](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_storageclass_reference).
* [Customizing storage classes](https://cloud.ibm.com/docs/containers?topic=containers-block_storageblock_custom_storageclass).







 Installing the IBM Cloud Block Storage for Classic plug-in in your cluster 

Install the IBM Cloud Block Storage for Classic plug-in with a Helm chart to set up pre-defined storage classes for Block Storage for Classic. You can use these storage classes to create a PVC to provision Block Storage for Classic for your apps.

Classic clusters that run IBM Cloud Kubernetes Service version 1.24 or later do not need to install the IBM Cloud Block Storage for Classic plug-in. The driver and plug-in are installed on these clusters by default.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. Make sure that your worker node applies the latest patch for your minor version to run your worker node with the latest security settings. The patch version also ensures that the root password on the worker node is renewed.
* Workloads that you want to increase high availability for by creating replicas in different zones and regions



Can I convert existing worker nodes to reserved worker nodes to save money?
: No. Instead, you can create reservations and contracts for the worker nodes in your clusters. Then, create worker pools in your existing clusters that use the reserved worker nodes. Consider using labels to reschedule your existing workloads to the new reserved worker pools. Then, delete your old, on demand worker pools.

How do reservations impact quotas?
: By default, Red Hat OpenShift on IBM Cloud sets a certain quota limit on the number of worker nodes that you can have across all clusters in a region. Contracts that exceed the worker node quota are blocked from creating. You can try a different region or increase the quota. If you need more of the resource, [contact IBM Support](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the support case, include the new quota limit for the region and infrastructure provider that you want. After the quota is increased, you can create a contract.

What happens when my contract ends? Are my worker nodes deleted?
: When a contract ends, your reservation is checked for extra capacity from other contracts. If you have more worker nodes than capacity, the worker nodes that exceed the reservation's total capacity are deleted.

For example, you might have a reservation with one contract for 10 worker nodes and another contract for 5 worker nodes, for a total capacity of 15 worker nodes. You use 14 of the 15 worker nodes. When the 5-worker node contract expires, your reservation total capacity reduces to 10 worker nodes. Therefore, 4 of your 14 running worker nodes are deleted, to make the number of worker nodes equal to the total capacity of 10 reserved worker nodes.

To avoid an unexpected deletion, scale down your worker pools before the contract ends to the remaining capacity in the reservation. Or, add contracts to your reservation so that you continue to have enough reserved capacity for the worker nodes that you need.





 Billing and discounts 

How much is the discount? Can I combine reservations with other discounts?
For example, if the cluster is in dal10, dal12, or dal13 zones, the replicas of the master are spread across each zone in the Dallas multizone metro.





 Do I have to do anything so that the master can communicate with the workers across zones? 

If you created a VPC multizone cluster, the subnets in each zone are automatically set up with Access Control Lists (ACLs) that allow communication between the master and the worker nodes across zones. In classic clusters, if you have multiple VLANs for your cluster, multiple subnets on the same VLAN, or a multizone classic cluster, you must enable a [Virtual Router Function (VRF)](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) for your IBM Cloud infrastructure account so your worker nodes can communicate with each other on the private network. To enable VRF, see [Enabling VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf). To check whether a VRF is already enabled, use the ibmcloud account show command. If you can't or don't want to enable VRF, enable [VLAN spanning](https://cloud.ibm.com/docs/vlans?topic=vlans-vlan-spanningvlan-spanning). To perform this action, you need the Network > Manage Network VLAN Spanning[infrastructure permission](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access), or you 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](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get).





 Can I convert my single zone cluster to a multizone cluster?
* Workloads that you want to increase high availability for by creating replicas in different zones and regions



Can I convert existing worker nodes to reserved worker nodes to save money?
: No. Instead, you can create reservations and contracts for the worker nodes in your clusters. Then, create worker pools in your existing clusters that use the reserved worker nodes. Consider using labels to reschedule your existing workloads to the new reserved worker pools. Then, delete your old, on demand worker pools.

How do reservations impact quotas?
: By default, IBM Cloud Kubernetes Service sets a certain quota limit on the number of worker nodes that you can have across all clusters in a region. Contracts that exceed the worker node quota are blocked from creating. You can try a different region or increase the quota. If you need more of the resource, [contact IBM Support](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar). In the support case, include the new quota limit for the region and infrastructure provider that you want. After the quota is increased, you can create a contract.

What happens when my contract ends? Are my worker nodes deleted?
: When a contract ends, your reservation is checked for extra capacity from other contracts. If you have more worker nodes than capacity, the worker nodes that exceed the reservation's total capacity are deleted.

For example, you might have a reservation with one contract for 10 worker nodes and another contract for 5 worker nodes, for a total capacity of 15 worker nodes. You use 14 of the 15 worker nodes. When the 5-worker node contract expires, your reservation total capacity reduces to 10 worker nodes. Therefore, 4 of your 14 running worker nodes are deleted, to make the number of worker nodes equal to the total capacity of 10 reserved worker nodes.

To avoid an unexpected deletion, scale down your worker pools before the contract ends to the remaining capacity in the reservation. Or, add contracts to your reservation so that you continue to have enough reserved capacity for the worker nodes that you need.





 Billing and discounts 

How much is the discount? Can I combine reservations with other discounts?
The OCP licenses are also part of the worker node plan and listed as a sub-item of the worker nodes in your IBM Cloud bill.





 Deprecated: Old OCP licenses for existing worker nodes before 9 November 2020 or deprecated bare metal flavors 

a Red Hat OpenShift license is billed for every four virtual cores (or two physical cores) of the worker node flavor. You are charged for the entire license for each month that you have worker nodes in a deployed state. The monthly charge applies to both virtual and physical worker nodes. For example, if you create the cluster on 15 August and delete the cluster on 14 September, you are still charged for the OCP licenses for two monthly periods: August and September.



* If you delete your worker node before the end of the month, your monthly license is available for other worker nodes in the same cluster. If the other worker nodes are not the same CPU size, you need additional licenses.
* If you delete the cluster before the end of the month, you are still charged the entire monthly price for the Red Hat OpenShift license.



When you estimate the cost of a new cluster or worker node, the OCP licenses are included as a separate line item. The OCP licenses are also listed as separate plans in your IBM Cloud bill.





 How can I migrate from the old to new OCP licenses? 

You can follow the same procedure to [update flavors](https://cloud.ibm.com/docs/openshift?topic=openshift-updatemachine_type) by adding new worker pools and removing the old worker pools. If you use bare metal, make sure that you use the latest series 4 flavors. Many existing bare metal flavors don't support the new OCP licenses.

You can check the new rates in the pricing estimate when you create a cluster or worker pool in the console. The OCP licenses are no longer a separate line item in the estimate, but instead are in the cost of the worker nodes.







 OCP licenses from Cloud Pak entitlements 

When you purchase products such as IBM Cloud Paks, your purchase might include OCP licenses. When you create a cluster or worker pool, you can choose to apply your entitlement to cover the cost of the OCP licenses.
: Optional: Do not show the message of the day or update reminders.



 Example worker replace command 

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







 ibmcloud oc worker rm 

Virtual Private Cloud

Classic infrastructure

Remove one or more worker nodes from a cluster. If you remove a worker node, your cluster becomes unbalanced, and [replacing a worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_worker_replace) no longer creates a replacement worker node. You can automatically rebalance your worker pool by running the ibmcloud oc worker-pool rebalance[command](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_rebalance) after you remove a worker node.

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

Minimum required permissions
: Operator platform access 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 options, 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 worker rm command 

ibmcloud oc worker rm --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2
In existing clusters, ALBs continue to run the previously supported IBM Cloud Kubernetes Service Ingress image, which is now deprecated. For more information and migration actions, see [Setting up Kubernetes Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).







 November 2020 



 24 November 2020 

New! Reservations to reduce classic worker node costs
: Create a reservation with contracts for 1 or 3 year terms for classic worker nodes to lock in a reduced cost for the life of the contract. Typical savings range between 30-50% compared to worker node costs. Reservations can be created in the IBM Cloud console for classic infrastructure only. For more information, see [Reserving instances to reduce classic worker node costs](https://cloud.ibm.com/docs/containers?topic=containers-reservations).





 23 November 2020 

Worker node versions
: Worker node fix pack update change log documentation is available.
: Kubernetes version [1.19.4_1527](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1191194_1527_worker), [1.18.12_1533](https://cloud.ibm.com/docs/containers?topic=containers-118_changelog11812_1533_worker), [1.17.14_1545](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog11714_1545_worker), and [1.16.15_1552](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog11615_1552_worker).





 20 November 2020 

New! Portieris for image security enforcement
: With the [open source Portieris project](https://github.com/IBM/portieris), you can set up a Kubernetes admission controller to enforce image security policies by namespace or cluster.
Managing classic infrastructure access 

When you invite a user to your account, you can select from three classic infrastructure permission sets that assign bulk access: View only, Basic user, Super user. You can update permissions for classic infrastructure services or add device and VPN subnet access for a user at any time. To access the classic infrastructure permissions, go to Manage > Access (IAM) in the IBM Cloud® console, select Users. Then, select the user's name that you want to update access for, and click Classic infrastructure.



 Classic infrastructure permissions 

When you invite someone to the account, only you, the account owner, or a user with the Manage user classic infrastructure permission, can adjust the permissions for the user. You can assign only the level of permissions or a subset of the permission that you're already assigned, if you're not the account owner. An account owner can update anyone's permissions in the account to have any level of access.

Extra permissions can be set after the user accepts the invitation. For example, the initial permission set assigned on the invitation doesn't grant access to devices. So, you must grant device access after the user accepts the invitation.

Support center account management access is recommended for users working with classic infrastructure resources. To perform many tasks when working with classic infrastructure resources, such as creating or deleting a virtual server instance, users must have access to work with support cases. For more information about assigning this type of access, see [Assigning access to account management services](https://cloud.ibm.com/docs/account?topic=account-account-services).

The following graphic shows how classic infrastructure permissions are assigned per user. You can grant each user access to a classic infrastructure service or device by selecting from the granular permission options to customize each user's access.

Zoom

![Classic infrastructure access](https://cloud.ibm.com/docs-content/v1/content/8188f85967d873aeb00bdd6c5f3fd757e84176ab/DataTransferService/includes/account/includes/account/images/ClassicIaaS.svg)
VRVDR-47897 8.1 DSA-4497-1 CVE-2015-8553, CVE-2018-5995, CVE-2018-20836 , CVE-2018-20856, CVE-2019-1125, CVE-2019-3882, CVE-2019-3900, CVE-2019-10207, CVE-201910638, CVE-2019-10639, CVE-2019-13631, CVE-2019-13648, CVE-2019-14283, CVE-2019-14284: DSA-4497-1: Linux – security update 









 1801zb 



 Issues Resolved 



Issues resolved for 1801zb

 Issue Number Priority Summary 

 VRVDR-47924 Major BGP 'show' output for default-vrf not captured in 'show tech-support' 
 VRVDR-47869 Minor L2TP/IPsec with x.509 authentication fails due to incorrect path to certificates 
 VRVDR-47711 Minor changing 'syslog global facility all level' overwrites individual 'facility <> level' settings 
 VRVDR-47710 Major nhrp overloads IPsec daemon communication 
 VRVDR-47661 Minor L2TP in high availability pair will not allow connections after VRRP failover 
 VRVDR-47606 Major Configuring "service https listen-address" bypasses the TLSv1.2 enforcement 
 VRVDR-47543 Blocker Long Login Delay due to pam_systemd failed to create session 
 VRVDR-47506 Minor ntpq segfault in ld-2.24.so 
 VRVDR-47485 Major VRRP snmp MIB stops working when any configuration changes made to SNMP 
 VRVDR-47381 Major When a vrrp vif is disabled the next change may prevent the interface from being displayed in 'show interfaces' 
 VRVDR-47229 Blocker netplugd crash on configuration change 
 VRVDR-46417 Major Dataplane is sending GRE packets sourced from non-exist VRRP VIP when router is BACKUP
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.26", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.26+IKS", GitCommit:"e15454c2216a73b59e9a059fd2def4e6712a7cf0", GitTreeState:"clean", BuildDate:"2019-04-01T10:08:07Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

The CLI versions match if you can see the same version in GitVersion for the client and the server. You can ignore the +IKS part of the version for the server.
2. If the kubectl CLI versions on your local machine and your cluster don't match, either update your cluster or [install a different CLI version on your local machine](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).