vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: The [cluster autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc) is available as a managed add-on. The cluster autoscaler Helm chart is deprecated. Migrate your autoscaled worker pools to use the add-on.

New! Community Kubernetes Ingress support
: The Ingress ALBs in your cluster can now run the Kubernetes Ingress image, which is built on the community Kubernetes project's implementation of the NGINX Ingress controller. To use the Kubernetes Ingress image, you create your Ingress resources and ConfigMaps according to the Kubernetes Ingress format, including community Kubernetes Ingress annotations instead of custom IBM Cloud Kubernetes Service annotations.

New! Default IBM Cloud® Certificate Manager instances
: An IBM Cloud Certificate Manager service instance is now created by default for all new and existing standard clusters. The Certificate Manager service instance, which is named in the format kube-crtmgr-<cluster_ID>, stores the TLS certificate for your cluster's default Ingress subdomain. You can also upload your own TLS certificates for custom Ingress domains to this Certificate Manager instance and use the new [ibmcloud ks ingress secret commands](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_ingress_secret_create) to create secrets for these certificates in your cluster. To ensure that a Certificate Manager instance is automatically created for your new or existing cluster, verify that the API key for the region and resource group that the cluster is created in has the correct Certificate Manager permissions.





 18 August 2020 

Versions
: Master fix pack update change log documentation is available.
: The [cluster-policy-controller](https://github.com/openshift/cluster-policy-controller) maintains policy resources that are required to create pods within the cluster.

cluster-version-operator
: The cluster version operator (CVO) installs and updates other operators that run in the cluster. For more information, see the [GitHub project](https://github.com/openshift/cluster-version-operator).

control-plane-operator
: The control plane operator manages the installation and update of control plane components in the master.

etcd, etcd-molecule, etcd-operator
: etcd is a highly available key value store that stores the state of all Kubernetes resources of a cluster, such as services, deployments, and pods. Data in etcd is backed up every 8 hours to an encrypted storage instance that IBM manages.

kube-controller-manager, openshift-controller-manager
: The [Kubernetes controller](https://github.com/openshift/cluster-kube-controller-manager-operator) watches the state of objects within the cluster, such as the replica set of a workload. When the state of an object changes, for example if a pod in a replica set goes down, the controller manager initiates correcting actions to achieve the required state. The Red Hat OpenShift controller performs the same function for objects that are specific to the Red Hat OpenShift API, such as projects.

kube-scheduler
: The [Kubernetes scheduler](https://github.com/openshift/cluster-kube-scheduler-operator) watches for newly created pods and decides where to deploy them based on capacity, performance needs, policy constraints, anti-affinity specifications, and workload requirements. If no worker node can be found that matches the requirements, the pod is not deployed in the cluster.

manifests-bootstrapper
: The manifests-boot-strapper job sets up the master with the required certificates to join as the master node of the cluster.

oauth-openshift
Terminology 

There are unique terms used in IBM Cloud® Security and Compliance Center Workload Protection.

Control
:   A control identifies a potential issue or violation within the environment and the solution to remediate the situation.

A control describes a rule, the code that is run to evaluate it, and a remediation playbook to fix the violation that might be detected. There are different types of controls to address business, security, compliance, and operational requirements. For more information, see [Posture controls](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-posture-controls).

Policy
:   A policy is a group of business, security, compliance, and operations requirements representing a compliance standard (for example, PCI 3.2.1), benchmark (for example, CIS Kubernetes 1.5.1) or business policy (for example, My corporation policy v1).

A policy includes one or more controls to define a compliance standard, a benchmark, or a business policy.

Policies can be [reviewed and new policies created.](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-manage-policies)

Requirement
:   A requirement includes 1 or more controls.

A requirement exists in a policy and represents a section within the policy that is familiar to compliance officers and auditors.

Requirement group
:   A requirement group defines the hierarchy and structure of controls in a policy. A requirement group consolidates one or more individual requirements within a policy.

Risk acceptance
:   Risk acceptance is the ability to review a violation or vulnerability and acknowledge it without remediating it. Risk acceptance will allow the policy to pass evaluation with the existing violation or vulnerability for a defined period of time.

Zone
:   A zone is a group of resources associated with a customer's business. Zones are defined by a collection of scopes or resource types.
Important: Before you disable the private endpoint, you first must complete the following steps to enable the public cloud service endpoint:



1. Enable the public cloud service endpoint by running ibmcloud oc cluster master public-service-endpoint enable --cluster <cluster_name>.
2. Follow the prompt in the CLI to refresh the Kubernetes master API server.
3. [Reload all the worker nodes in your cluster to pick up the public endpoint configuration.](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_reload)



ibmcloud oc cluster master private-service-endpoint disable --cluster CLUSTER [-f] [-q] [-y]

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

Command options:

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

-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 cluster master private-service-endpoint disable command 

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







 ibmcloud oc cluster master private-service-endpoint enable 

Classic infrastructure

Enable the [private cloud service endpoint](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsworkeruser-master) to make your cluster master privately accessible.

To run this command:



1. Enable [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) in your IBM Cloud infrastructure account. To check whether a VRF is already enabled, use the ibmcloud account show command.
2.
Verify that the audit webhook is created in your cluster.

ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>

Example output

OK
Server: https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy: default
11. Apply the webhook to your Kubernetes API server by refreshing the cluster master. The master might take several minutes to refresh.

ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>



After the master refresh completes, your logs are sent to the private IP address of your logging resource.





 Forwarding Kubernetes API audit logs to an external server on the public Internet 

To audit any events that are passed through your Kubernetes API server, you can create a configuration that uses Fluentd to forward events to an external server.

Before you begin, ensure that you reviewed the [considerations and prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-health-auditprereqs-apiserver-logs). Note that [log filters](https://cloud.ibm.com/docs/containers?topic=containers-healthfilter-logs) are not supported.



1. Set up the webhook. If you don't provide any information in the options, a default configuration is used.

ibmcloud ks cluster master audit-webhook set --cluster <cluster_name_or_ID> --remote-server <server_URL_or_IP> --ca-cert <CA_cert_path> --client-cert <client_cert_path> --client-key <client_key_path>



Table 1. Understanding this command's components

 Option Description 

 <cluster_name_or_ID> The name or ID of the cluster. 
 <server_URL> A publicly accessible URL or IP address for the remote logging service that you want to send logs to.
Public traffic to cluster apps 

To make your apps accessible from the public internet, you can use public networking services. Even though your worker nodes are connected to private VPC subnets only, the VPC load balancer that is created for public networking services can route public requests to your app on the private network by providing your app a public URL. When an app is publicly exposed, anyone that has the public URL can send a request to your app.

You can use public Kubernetes networking services, such as creating [LoadBalancer services](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas). For example, when you create a Kubernetes LoadBalancer service in your cluster, a load balancer for VPC is automatically created in your VPC outside of your cluster. The VPC load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. For VPC ALBs, a [security group](https://cloud.ibm.com/docs/containers?topic=containers-vpc-security-group), named in the form of kube-<vpc-id>, is automatically attached to your ALB instance.

The kube-<vpc-id> security group that is attached to your VPC ALB is the same security group used for the private VPE gateway that communicates with the Kubernetes master. Do not modify this security group, as doing so might result in disruptions to the network connectivity between the cluster and the Kubernetes master. Instead, you can [remove the security group from the VPC ALB](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-remove) and [replace it with a security group](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-add) that you create and manage.
Even though your worker nodes are connected to private VPC subnets only, the VPC load balancer that is created for public networking services can route public requests to your app on the private network by providing your app a public URL. When an app is publicly exposed, anyone that has the public URL can send a request to your app.

You can use public Kubernetes networking services, such as creating [LoadBalancer services](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas). For example, when you create a Kubernetes LoadBalancer service in your cluster, a load balancer for VPC is automatically created in your VPC outside of your cluster. The VPC load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. For VPC ALBs, a [security group](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-security-group), named in the form of kube-<vpc-id>, is automatically attached to your ALB instance.

The kube-<vpc-id> security group that is attached to your VPC ALB is the same security group used for the private VPE gateway that communicates with the Kubernetes master. Do not modify this security group, as doing so might result in disruptions to the network connectivity between the cluster and the Kubernetes master. Instead, you can [remove the security group from the VPC ALB](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-remove) and [replace it with a security group](https://cloud.ibm.com/docs/vpc-infrastructure-cli-plugin?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=clisecurity-group-target-add) that you create and manage.





 Example scenarios for VPC cluster network setups
For example, the mention France in the statement, the students went to France, is marked with the entity type GPE because France is a geo-political entity. But, because France in this context is also a destination for the traveling students, the entity type is qualified by adding an attribute, in this case the role LOCATION. For another example, the mention Lawyers might be marked with the entity type PEOPLE and also by the role OCCUPATION.
* Entity subtype

Further classifies the entity type. For example, the entity type ORGANIZATION might include the subtypes COMMERCIAL, GOVERNMENT, MILITARY, and EDUCATION.
* Mention type

Qualifies the mention by certain parts of speech:



* NAM: the mention is a proper name, such as a person's name or the name of an organization.
* NOM: the mention is nominal (a common noun), such as company or president.
* PRO: the mention is a pronoun, such as he, we, or it.
* NONE: none of the other three mention types are applicable.



* Mention class

Qualifies the mention by indicating whether the mention is specific, generic, or negated:



* SPC: the mention is specific, often including the word the in English, such as the book or the hurricane occurred in September. In these examples, the mentions book and hurricane would be annotated with the attribute SPC.
* GEN: the mention is generic, such as a book or hurricanes usually occur in the fall. In these examples, the mentions book and hurricanes would be annotated with the attribute GEN.
* NEG: the mention is negated, such as references to no book. When you train a model, the algorithm can learn from both negative and positive examples, so it's important to mark mentions of both types.









 Relation types 

A relation type defines a binary, ordered relationship between two entities. For a relation mention to exist, text must explicitly define the relation and bind mentions of the two entities together, and must do so within a single sentence. For example, the sentence Mary works for IBM is textual evidence of the employedBy relation type.

For some relation types, the order of entity mentions matters.
To change the default storage for your cluster, see this topic on [Persistent storage considerations](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-deploy-iksibp-console-storage) to learn more.
* Now that your console is ready to use, you can go ahead to the [Build a network tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network). Consider bookmarking the URL of your console so you can come back at a later time if needed. Otherwise, you can follow the steps in the [Post-install instructions](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-deploy-iks-icibp-v2-deploy-iks-post-install) to get back to it from your browser.







 Updating the Kubernetes version of your cluster 

If you use an existing IBM Cloud Kubernetes service cluster, ensure that it is running Kubernetes v1.24 - v1.26.

Before upgrading to Kubernetes version v1.24 - v1.26, ensure that you have migrated to [Kubernetes ingress controllers](https://cloud.ibm.com/docs/containers?topic=containers-ingress-typesabout-alb-images).

You can check the Kubernetes version of your cluster in the [Kubernetes clusters page](https://cloud.ibm.com/kubernetes/clusters) on IBM Cloud, which lists all your clusters in a table.

For instructions on how to update Kubernetes, see [Updating clusters, worker nodes, and cluster components](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate). For the list of IBM Cloud Kubernetes Service supported versions and expiration dates see the [release history](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsrelease-history).
: Optional: Do not show the message of the day or update reminders.



 Example cluster ca status command 

ibmcloud ks cluster ca status --cluster my_cluster







 ibmcloud ks cluster config 

Virtual Private Cloud

Classic infrastructure

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

The kubeconfig file is merged to your 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 command line session. After you run ibmcloud ks cluster config, you can interact with your cluster immediately, and quickly change the context to other clusters in the Kubernetes context.

ibmcloud ks cluster config --cluster CLUSTER [--admin] [--endpoint ENDPOINT_TYPE] [--network] [--skip-rbac] [-q] [--yaml]

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



* Platform: If you have only a platform access role, you can perform this command, but you need a [service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) or a [custom RBAC policy](https://cloud.ibm.com/docs/containers?topic=containers-access-overviewrole-binding) to perform Kubernetes actions in the cluster.
* Service: If you have only a service access role, you can perform this command. However, your cluster admin must give you the cluster name and ID because you can't run the ibmcloud ks cluster ls command or open the IBM Cloud Kubernetes Service console to view clusters.
: As part of cluster resource instances in IBM Cloud IAM, you can assign users with service access roles to namespaces within your clusters. When you assign access to a namespace, the policy applies to all current and future instances of the namespace in all the clusters that you authorize. For example, say that you want a dev group of users to be able to deploy Kubernetes resources in a test namespace in all your clusters in AP North. If you assign the dev access group the Writer service access role for the Kubernetes namespace test in all clusters in the AP North region within the default resource group, the dev group can access the test namespace in any AP North cluster in the default resource group that currently has or eventually has a test namespace. If you scope a service access role to a namespace, you can't apply the policy to a resource group or assign a platform access role at the same time.

Resource group
: You can organize your account resources in customizable groupings so that you can quickly assign individual or groups of users access to more than one resource at a time. Resource groups can help operators and administrators filter resources to view their current usage, troubleshoot issues, and manage teams.
: A cluster can be created in only one resource group that you can't change afterward. If you create a cluster in the wrong resource group, you must delete the cluster and re-create it in the correct resource group. Furthermore, if you need to use the ibmcloud oc cluster service bind command to [integrate with an IBM Cloud service](https://cloud.ibm.com/docs/openshift?topic=openshift-service-bindingbind-services), that service must be in the same resource group as the cluster. Services that don't use resource groups like IBM Cloud Container Registry or that don't need service binding like IBM Log Analysis work even if the cluster is in a different resource group.
: 

* Consider giving clusters unique names across resource groups and regions in your account to avoid naming conflicts. You can't rename a cluster.
* You can assign users an access role to a resource group to grant permissions as described in the following scenarios.
Logging with infrastructure overview 

In Log Analysis, you can send infrastructure logs to an IBM Log Analysis instance from a broad range of sources:



 Logging with Kubernetes clusters 

You can configure a logging agent to collect logs from a Kubernetes cluster and forward them to an instance of the IBM Log Analysis service.

You can collect and monitor logs from a Kubernetes cluster that is located in the same IBM Cloud region as your IBM Log Analysis instance or in a different one. You can also collect and monitor logs from clusters that are located outside the IBM Cloud.

To configure cluster-level logging for a Kubernetes cluster, you must complete the following steps:



1. Provision an instance of the IBM Log Analysis service. With this step, you configure a centralized log management system where log data is hosted on IBM Cloud.
2. Provision a cluster, for example, a standard cluster on the IBM Cloud Kubernetes Service.
3. Deploy and configure the logging agent in the cluster.



Zoom

![Log Analysis component overview on the IBM Cloud](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/Log-Analysis-02-Kubernetes.svg)

Log Analysis component overview on the IBM Cloud for Kubernetes

For more information, see [Logging with Kubernetes clusters](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-kube).





 Logging with Bare metal 

You can use the IBM® Log Analysis service to monitor and manage logs from a bare metal in a centralized logging system on the IBM Cloud. You can collect and monitor system and application logs.

By default, the logging agent on Linux servers monitors log files in the /var/log directory. For example, the Ubuntu system log (/var/log/syslog) is monitored by default.
: v1 API: Responses include only information that is specific to the classic infrastructure provider, such as the VLANs in GET cluster and worker responses.
: v2 API: The information that is returned varies depending on the infrastructure provider. For such provider-specific responses, you can specify the provider in your request. For example, VPC clusters don't return VLAN information since they don't have VLANs. Instead, they return subnet and CIDR network information.





 Automating cluster deployments with the API 

You can use the IBM Cloud Kubernetes Service API to automate the creation, deployment, and management of your Kubernetes clusters.

The IBM Cloud Kubernetes Service API requires header information that you must provide in your API request and that can vary depending on the API that you want to use. To determine what header information is needed for your API, see the [IBM Cloud Kubernetes Service API documentation](https://containers.cloud.ibm.com/global/swagger-global-api//).

To authenticate with IBM Cloud Kubernetes Service, you must provide an IBM Cloud Identity and Access Management (IAM) token that is generated with your IBM Cloud credentials and that includes the IBM Cloud account ID where the cluster was created. Depending on the way you authenticate with IBM Cloud, you can choose between the following options to automate the creation of your IBM Cloud IAM token.

You can also use the [API swagger JSON file](https://containers.cloud.ibm.com/global/swagger-global-api/swagger.json) to generate a client that can interact with the API as part of your automation work.

Unfederated ID
: 

* Generate an IBM Cloud API key: As an alternative to using the IBM Cloud username and password, you can [use IBM Cloud API keys](https://cloud.ibm.com/docs/account?topic=account-userapikeycreate_user_key). IBM Cloud API keys are dependent on the IBM Cloud account they are generated for. You can't combine your IBM Cloud API key with a different account ID in the same IBM Cloud IAM token.