vania-janet/multiturn-rag-retrieval-data huggingface dataset:
What are IAM policies and who can assign them? 

A policy grants a subject one or multiple roles to a set of resources so that specific actions can be taken within the context of the specified target resources.

The following graphic helps to explain how the IAM policy is created. Policies are always created by specifying the subject first. The subject is a specific user, service ID, access group, or a trusted profile. Next, the target of the policy is selected which is what you are allowing the user to access, for example: all services in a resource group, all IAM-enabled services in the account, account management services, or a particular service instance. Finally, you complete your access policy by selecting from the available roles. These roles define exactly what actions that a user can complete. More configuration options might be available, depending on the service you select.

Zoom

![Creating IAM policies](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/account/images/IAM.svg)

Figure 1. How IAM access policies are created by using a subject, target, and role

You can assign and manage policies if you have the proper role. The following table shows policy management tasks and the role that is required for each.



Table 1. Users allowed to create access policies

 Action Required role 

 Create a policy in an account for all services and instances Account owner or administrator on all account management services and all Identity and Access enabled services 
 Create a policy on a service in an account Account owner, administrator on all Identity and Access enabled services, or administrator on the service in the account 
 Create a policy on a service instance Account owner, administrator on all Identity and Access enabled services, administrator on the service in the account, administrator on all services in the relevant resource group, or administrator on the service instance 





 Common access policy types 

You can provide fine-grained access for users, service IDs, or access groups by assigning the following types of access policies:



* All Account Management services
* A specific account management service
What are IAM policies and who can assign them? 

A policy grants a subject one or multiple roles to a set of resources so that specific actions can be taken within the context of the specified target resources.

The following graphic helps to explain how the IAM policy is created. Policies are always created by specifying the subject first. The subject is a specific user, service ID, access group, or a trusted profile. Next, the target of the policy is selected which is what you are allowing the user to access, for example: all services in a resource group, all IAM-enabled services in the account, account management services, or a particular service instance. Finally, you complete your access policy by selecting from the available roles. These roles define exactly what actions that a user can complete. More configuration options might be available, depending on the service you select.

Zoom

![Creating IAM policies](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/IAM.svg)

Figure 1. How IAM access policies are created by using a subject, target, and role

You can assign and manage policies if you have the proper role. The following table shows policy management tasks and the role that is required for each.



Table 1. Users allowed to create access policies

 Action Required role 

 Create a policy in an account for all services and instances Account owner or administrator on all account management services and all Identity and Access enabled services 
 Create a policy on a service in an account Account owner, administrator on all Identity and Access enabled services, or administrator on the service in the account 
 Create a policy on a service instance Account owner, administrator on all Identity and Access enabled services, administrator on the service in the account, administrator on all services in the relevant resource group, or administrator on the service instance 





 Common access policy types 

You can provide fine-grained access for users, service IDs, or access groups by assigning the following types of access policies:



* All Account Management services
* A specific account management service
Migrating to a new Ubuntu version 

To migrate your worker nodes to a new Ubuntu version, you must provision a new worker pool, add worker nodes to the new pool, then remove the original worker pool.

Ubuntu 20 is the default operating system for all supported IBM Cloud Kubernetes Service cluster versions. Ubuntu 18 becomes unsupported on 5 June 2023. To avoid disruptions to your workload, migrate your worker nodes from Ubuntu 18 to Ubuntu 20 as soon as possible.

With the release of Ubuntu 20, some worker node flavors are deprecated. If you have worker nodes with these flavors, you must provision worker nodes with a new flavor during the migration process. The deprecated flavors are: mb3c.4x32, mb3c.16x64, ms3c.4x32.1.9tb.ssd, ms3c.16x64.1.9tb.ssd, ms3c.28x256.3.8tb.ssd, ms3c.28x512.4x3.8tb.ssd, mr3c.28x512, md3c.16x64.4x4tb, md3c.28x512.4x4tb, mg3c.16x128, mg3c.28x256.



 Prerequisites 



1. Review your worker pool operating systems to determine which pools you need to migrate.

ibmcloud ks worker-pools -c CLUSTER
2. For the worker pools that you want to migrate, review the details of the worker pool.

ibmcloud ks worker-pool get --cluster CLUSTER --worker-pool WORKER-POOL
3. In the output, note the zone and either the private and public VLAN ID for Classic clusters or the subnet ID for VPC clusters. Also note any custom labels that you are using. The default worker pool label is ibm-cloud.kubernetes.io. Any labels other than ibm-cloud.kubernetes.io are custom labels that you should add to your new worker pool.







 Migration steps
scaleDownCandidatesPoolMinCount The minimum number of nodes that are considered as additional non-empty candidates for scale down when some candidates from previous iterations are no longer valid. 50 
 scaleDownEnabled When set to false, the autoscaler does not perform scale down. true 
 scaleDownUnreadyEnabled When set to true unready nodes are scheduled for scale down. true 
 scanInterval Set how often in minutes that the cluster autoscaler scans for workload usage that triggers scaling up or down. 1m 
 skipNodesWithLocalStorage When set to true, worker nodes that have pods that are saving data to local storage are not scaled down. The default value is true 
 skipNodesWithSystemPods When set to true, worker nodes that have kube-system pods are not scaled down. Do not set the value to false because scaling down kube-system pods might have unexpected results. true 
 expendablePodsPriorityCutoff Pods with priority under the cutoff are expendable. They can be removed without consideration during scale down and they don't cause scale up. Pods that PodPriority set to null are not expendable. -10 
 minReplicaCount The minimum number of replicas that a replicaSet or replication controller must allow to be deleted during scale down. 0 
 newPodScaleUpDelay Pods newer than this value in seconds are not considered for scale-up. Can be increased for individual pods through the cluster-autoscaler.kubernetes.io/pod-scale-up-delay annotation. 0s 
 balancingIgnoreLabel The node labels to ignore during zone balancing. Apart from the fixed node labels, the autoscaler can ignore an additional 5 node labels during zone balancing. For example: balancingIgnoreLabel:key1=value1 and balancingIgnoreLabel:key2=value2
(E0011)
3. If the worker node is not removed, review the [State and Status fields](https://cloud.ibm.com/docs/containers?topic=containers-debug_worker_nodes) and the [common issues with worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-common_worker_nodes_issues) to continue debugging.
4. If you manually set credentials and still can't see the cluster's worker nodes in your infrastructure account, you might check whether the [cluster is orphaned](https://cloud.ibm.com/docs/containers?topic=containers-cluster_infra_errorsorphaned).









 Unable to create or delete worker nodes due to incorrect account error 

Classic infrastructure

 What’s happening 

You can't manage worker nodes for your cluster or view the cluster worker nodes in your classic IBM Cloud infrastructure account. However, you can update and manage other clusters in the account.

Further, you verified that you have the [proper infrastructure credentials](https://cloud.ibm.com/docs/containers?topic=containers-cluster_infra_errorscs_credentials).

You might receive an error message in your worker node status similar to the following example.

incorrect account for worker - The 'classic' infrastructure user credentials changed and no longer match the worker node instance infrastructure account.

 Why it’s happening 

The cluster might be provisioned in a classic IBM Cloud infrastructure account that is no longer linked to your IBM Cloud Kubernetes Service account. The cluster is orphaned. Because the resources are in a different account, you don't have the infrastructure credentials to modify the resources.

Consider the following example scenario to understand how clusters might become orphaned.



1. You have an IBM Cloud Pay-As-You-Go account.
2. You create a cluster named Cluster1. The worker nodes and other infrastructure resources are provisioned into the infrastructure account that comes with your Pay-As-You-Go account.
3. Later, you find out that your team uses a legacy or shared classic IBM Cloud infrastructure account.
Classic: Why do I see a timeout error when I try to log in to a pod on a new worker node? 

Classic infrastructure

 What’s happening 

You deleted a worker node in your cluster and then added a worker node. When you deployed a pod or Kubernetes service, the resource can't access the newly created worker node, and the connection times out.

 Why it’s happening 

If you delete a worker node from your cluster and then add a worker node, the new worker node might be assigned the private IP address of the deleted worker node. Calico uses this private IP address as a tag and continues to try to reach the deleted node.

 How to fix it 

Manually update the reference of the private IP address to point to the correct node.



1. Confirm that you have two worker nodes with the same Private IP address. Note the Private IP and ID of the deleted worker.

ibmcloud ks worker ls --cluster <cluster_name_or_id>

ID Public IP Private IP Machine Type State Status Zone Version
kube-dal10-cr9b7371a7fcbe46d08e04f046d5e6d8b4-w1 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 normal Ready dal10 1.26
kube-dal10-cr9b7371a7fcbe46d08e04f046d5e6d8b4-w2 169.xx.xxx.xxx 10.xxx.xx.xxx b3c.4x16 deleted - dal10 1.26
2. Install the [Calico CLI](https://cloud.ibm.com/docs/containers?topic=containers-network_policiescli_install).
3. List the available worker nodes in Calico. Replace <path_to_file> with the local path to the Calico configuration file.

calicoctl get nodes --config=filepath/calicoctl.cfg

NAME
IBM Cloud storage utilities 



 Classic: Installing the IBM Cloud Block Storage Attacher plug-in (beta) 

Use the IBM Cloud Block Storage Attacher plug-in to attach raw, unformatted, and unmounted block storage to a classic worker node in your cluster.

The IBM Cloud Block Storage Attacher plug-in is available for classic worker nodes only. If you want to attach raw, unformatted block storage to a VPC worker node, see [Adding raw Block Storage for VPC worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_api_attach).

For example, you want to store your data with a software-defined storage solution (SDS), such as [Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_about), but you don't want to use classic bare metal worker nodes that are optimized for SDS usage and that come with extra local disks. To add local disks to your classic non-SDS worker node, you must manually create your block storage devices in your IBM Cloud infrastructure account and use the IBM Cloud Block Volume Attacher to attach the storage to your non-SDS worker node.

The IBM Cloud Block Volume Attacher plug-in creates pods on every worker node in your cluster as part of a daemon set and sets up a Kubernetes storage class that you later use to attach the block storage device to your non-SDS worker node.

Looking for instructions for how to update or remove the IBM Cloud Block Volume Attacher plug-in? See [Updating the plug-in](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesupdate_block_attacher) and [Removing the plug-in](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesremove_block_attacher).



1.
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 ks worker-pool rebalance --cluster CLUSTER --worker-pool WORKER_POOL [-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.

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

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



 Example worker-pool rebalance command 

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







 ibmcloud ks worker-pool resize 

Virtual Private Cloud

Classic infrastructure

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

ibmcloud ks worker-pool resize --cluster CLUSTER --worker-pool WORKER_POOL --size-per-zone WORKERS_PER_ZONE [-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 for which you want to resize worker pools.

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

--size-per-zone WORKERS_PER_ZONE
: The number of workers that you 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?](https://cloud.ibm.com/docs/containers?topic=containers-faqssmallest_cluster).

-q
IBM Cloud storage utilities 



 Classic: Installing the IBM Cloud Block Storage Attacher plug-in (beta) 

Use the IBM Cloud Block Storage Attacher plug-in to attach raw, unformatted, and unmounted block storage to a classic worker node in your cluster.

The IBM Cloud Block Storage Attacher plug-in is available for classic worker nodes only. If you want to attach raw, unformatted block storage to a VPC worker node, see [Adding raw Block Storage for VPC worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesvpc_api_attach).

For example, you want to store your data with a software-defined storage solution (SDS), such as [Portworx](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_about), but you don't want to use classic bare metal worker nodes that are optimized for SDS usage and that come with extra local disks. To add local disks to your classic non-SDS worker node, you must manually create your block storage devices in your IBM Cloud infrastructure account and use the IBM Cloud Block Volume Attacher to attach the storage to your non-SDS worker node.

The IBM Cloud Block Volume Attacher plug-in creates pods on every worker node in your cluster as part of a daemon set and sets up a Kubernetes storage class that you later use to attach the block storage device to your non-SDS worker node.

Looking for instructions for how to update or remove the IBM Cloud Block Volume Attacher plug-in? See [Updating the plug-in](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesupdate_block_attacher) and [Removing the plug-in](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesremove_block_attacher).



1. [Follow the instructions](https://cloud.ibm.com/docs/containers?topic=containers-helminstall_v3) to install the Helm client version 3 on your local machine.
2.
* Persistent modifications: For modifications to persist across worker node lifecycle operations, create a daemon set that uses an init container. For more information, see [Modifying default worker node settings to optimize performance](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker).



Modifications to the operating system are not supported. If you modify the default settings, you are responsible for debugging and resolving the issues that might occur.





 Hardware changes 

To change the compute hardware, such as the CPU and memory per worker node, choose among the following options.



* [Create a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workers). The instructions vary depending on the type of infrastructure for the cluster, such as classic, VPC, or gateway clusters.
* [Update the flavor](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type) in your cluster by creating a worker pool and removing the previous worker pool.









 Modifying worker node settings to optimize performance 



 Modifying worker node kernel settings 

If you have specific performance optimization requirements, you can change the default settings for the Linux kernel sysctl parameters on worker nodes.

Worker nodes are automatically provisioned with optimized kernel performance, but you can change the default settings by applying a custom [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) with an [init Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) to your cluster. The daemon set modifies the settings for all existing worker nodes and applies the settings to any new worker nodes that are provisioned in the cluster. The init container makes sure that these modifications occur before other pods are scheduled on the worker node. No pods are affected.

You must have the [Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) for all namespaces to run the sample privileged initContainer.
Why do ALB pods not deploy to worker nodes? 

Virtual Private Cloud

Classic infrastructure

 What’s happening 

When you run kubectl get pods -n kube-system | grep alb, either no ALB pods or only some ALB pods successfully deployed to your worker nodes.

When you describe an ALB pod by running kubectl describe pod -n kube-system <pod_name>, you see a message similar to the following in the Events section of the output.

0/3 nodes are available: 1 node(s) didn’t match pod affinity/anti-affinity, 2 node(s) didn’t match node selector.

 Why it’s happening 

Ingress requires at least two worker nodes per zone to ensure high availability and apply periodic updates.

 How to fix it 

By default, ALB pods have two replicas. However, ALB pods have anti-affinity rules to ensure that only one pod is scheduled to each worker node for high availability. When only one worker node exists per zone in a classic or VPC cluster, or if only one worker node exists on a VLAN that your classic cluster is attached to, ALB pods can't deploy correctly.



1. Check the number of worker nodes per zone in your cluster.

ibmcloud ks worker ls -c <cluster_name_or_ID>



* Classic and VPC clusters: If only one worker node exists in a zone, increase the number of worker nodes in that zone.



* If you don't use edge nodes: Ensure that at least two worker nodes exist in each zone by [resizing an existing worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersresize_pool), [creating a new worker pool in a VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersvpc_add_pool), or [creating a new worker pool in a classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool).
Classic: Why is the bare metal instance ID inconsistent with worker records? 

Classic infrastructure

  What’s happening 

When you use ibmcloud ks worker commands with your bare metal worker node, you see a message similar to the following.

The worker node instance ID changed. Reload the worker node if bare metal hardware was serviced.

  Why it’s happening 

The machine ID can become inconsistent with the IBM Cloud Kubernetes Service worker record when the machine experiences hardware issues. When IBM Cloud infrastructure resolves this issue, a component can change within the system that the service does not identify.

  How to fix it 

For IBM Cloud Kubernetes Service to re-identify the machine, [reload the bare metal worker node](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload). Note that reloading also updates the machine's [patch version](https://cloud.ibm.com/docs/containers?topic=containers-changelog).

You can also [delete the bare metal worker node](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_rm). Remember that bare metal instances are billed monthly.
* Force a one-time update when you use a logging command that includes the --force-update option. Note: Your pods update to the latest version of the Fluentd component, but Fluentd does not update automatically going forward. Example command

ibmcloud ks logging config update --cluster CLUSTER --id LOG-CONFIG-ID --type LOG-TYPE --force-update









 Managing automatic updates for Ingress ALBs 

Control when the Ingress application load balancer (ALB) component is updated. For information about keeping ALBs up-to-date, see [Managing the Ingress ALB lifecycle](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about).







 Updating managed add-ons 

Managed IBM Cloud Kubernetes Service add-ons are an easy way to enhance your cluster with open-source capabilities, such as Istio. The version of the open-source tool that you add to your cluster is tested by IBM and approved for use in IBM Cloud Kubernetes Service. To update managed add-ons that you enabled in your cluster to the latest versions, see [Updating managed add-ons](https://cloud.ibm.com/docs/containers?topic=containers-managed-addonsupdating-managed-add-ons).





 Updating from stand-alone worker nodes to worker pools 

With the introduction of multizone clusters, worker nodes with the same configuration, such as the machine type, are grouped in worker pools. When you create a new cluster, a worker pool that is named default is automatically created for you.

Applies to only classic clusters. VPC clusters always use worker pools.

You can use worker pools to spread worker nodes evenly across zones and build a balanced cluster. Balanced clusters are more available and resilient to failures. If a worker node is removed from a zone, you can rebalance the worker pool and automatically provision new worker nodes to that zone. Worker pools are also used to install Kubernetes version updates to all your worker nodes.

If you created clusters before multizone clusters became available, your worker nodes are still stand-alone and not automatically grouped into worker pools.