vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Kubernetes v1.21.9 v1.21.10 For more information, see the [change logs](https://github.com/kubernetes/kubernetes/releases/tag/v1.21.10). 
 HA proxy f6a2b3 15198fb Contains fixes for [CVE-2022-24407](https://nvd.nist.gov/vuln/detail/CVE-2022-24407), 







 Change log for worker node fix pack 1.21.9_1549, released 14 February 2022 



Changes since version 1.20.15_1569

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A N/A 
 Kubernetes N/A N/A N/A 
 HA proxy d38fa1 f6a2b3 [CVE-2021-3521](https://nvd.nist.gov/vuln/detail/CVE-2021-3521)[CVE-2021-4122](https://nvd.nist.gov/vuln/detail/CVE-2021-4122). 







 Change log for worker node fix pack 1.21.9_1548, released 31 January 2022 



Changes since version 1.20.13_1567

 Component Previous Current Description
In the following Kubernetes job, a curl pod makes an API request to IBM Cloud IAM to verify that the cluster's public key is exchanged for an IAM access token. Your app might call other IBM Cloud services that the trusted profile authorizes.

apiVersion: batch/v1
kind: Job
metadata:
name: token-exchange-job
namespace: default
spec:
template:
spec:
containers:
- name: curl
image: curlimages/curl:7.77.0
command: ["/bin/sh"]
args: ["-c", "curl -s -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" -d grant_type=urn:ibm:params:oauth:grant-type:cr-token -d cr_token=$(cat /var/run/secrets/tokens/sa-token) -d profile_id=<profile_id> https://iam.cloud.ibm.com/identity/token"]
volumeMounts:
- mountPath: /var/run/secrets/tokens
name: sa-token
restartPolicy: Never
serviceAccountName: default
volumes:
- name: sa-token
projected:
sources:
- serviceAccountToken:
path: sa-token
expirationSeconds: 3600
audience: iam
Show more
4. Deploy the job.

kubectl apply -f exchange-job.yaml
5. Review the job details to verify it was successful.

oc describe job token-exchange-job
6. Review the output for the job completed and succeeded messages to verify the job was a success.
7. If the job succeeded, check your Activity Tracker global events in Frankfurt to verify the log line with details on the Trusted Profile request. If the job failed, review your configuration and try again.
: Kubernetes [1.17.5_1523](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog1175_1523), [1.16.9_1530](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog1169_1530), [1.15.11_1537](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog11511_1537), and [1.14.10_1553](https://cloud.ibm.com/docs/containers?topic=containers-114_changelog11410_1553)





 23 April 2020 

Version change logs
: Kubernetes [1.17.5_1522](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog1175_1522), [1.16.9_1529](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog1169_1529), [1.15.11_1536](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog11511_1536), and [1.14.10_1552](https://cloud.ibm.com/docs/containers?topic=containers-114_changelog11410_1552).





 22 April 2020 

Private network connection to registry
: For accounts that have VRF and service endpoints enabled, image push and pull traffic to IBM Cloud Container Registry is now on [the private network](https://cloud.ibm.com/docs/containers?topic=containers-registrycluster_registry_auth_private).





 17 April 2020 

Version change log
: Master patch updates are available for Kubernetes [1.17.4_1521](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog1174_1521_master).





 16 April 2020
Kubernetes configuration N/A N/A Updated the [feature gate configuration](https://cloud.ibm.com/docs/containers?topic=containers-service-settingsfeature-gates) 
 Kubernetes Metrics Server v0.4.4 v0.4.5 Metrics server now dynamically reloads NannyConfiguration updates. See the [Kubernetes Metrics Server release notes](https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.4.5). 
 Kubernetes NodeLocal DNS cache 1.21.1 1.21.3 See the [Kubernetes NodeLocal DNS cache release notes](https://github.com/kubernetes/dns/releases/tag/1.21.3). 
 Load balancer and load balancer monitor for IBM Cloud Provider 1659 1747 Updated the Alpine base image to the 3.15 version to resolve CVEs. Updated to use Go version 1.17.6. 







 Change log for worker node fix pack 1.21.7_1546, released 18 January 2022 



Changes since version 1.21.7_1544

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-163-generic 4.15.0-166-generic Kernel and package updates for [CVE-2018-25020](https://nvd.nist.gov/vuln/detail/CVE-2018-25020) and [CVE-2021-4002](https://nvd.nist.gov/vuln/detail/CVE-2021-4002). 
 Containerd v1.5.8 v1.5.9 See the [change log](https://github.com/containerd/containerd/releases/tag/v1.5.9). 







 Change log for worker node fix pack 1.21.7_1544, released 4 January 2022 

The following table shows the changes that are in the worker node fix pack patch update 1.21.7_1544.
When you create a new ALB, enable an ALB that was previously disabled, or manually update an ALB, you can specify an image version for your ALB in the --version option. The latest three versions of the Kubernetes Ingress image are supported for ALBs. To list the currently supported versions, run the following command:

ibmcloud ks ingress alb versions

The Kubernetes Ingress version follows the format <community_version>_<ibm_build>_iks. The IBM build number indicates the most recent build of the Kubernetes Ingress NGINX release that IBM Cloud Kubernetes Service released. For example, the version 1.1.2_2507_iks indicates the most recent build of the 0.47.0 Ingress NGINX version. IBM Cloud Kubernetes Service might release builds of the community image version to address vulnerabilities.

When automatic updates are enabled for ALBs, your ALBs are updated to the most recent build of the version that is marked as default. If you want to use a version other than the default, you must [disable automatic updates](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_alb_autoupdate_disable). Typically, the latest version becomes the default version one month after the latest version is released by the Kubernetes community. Actual availability and release dates of versions are subject to change and depend on various factors, such as community updates, security patches, and technology changes between versions.





 Version 1.6.4 



 1.6.4_5161_iks, released 5 July 2023 



* Resolves [CVE-2023-32731](https://nvd.nist.gov/vuln/detail/CVE-2023-32731)







 1.6.4_5067_iks, released 6 June 2023 



* Updates golang version to 1.20.4.
* [CVE-2023-29491](https://nvd.nist.gov/vuln/detail/CVE-2023-29491)
For example, [Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)oc client versions that are 2 or more versions apart from the server version (n +/- 2).



1. Verify that the oc CLI version that you run on your local machine matches the Kubernetes version that is installed in your cluster. Show the oc CLI version that is installed in your cluster and your local machine.

oc version

Example output:

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 oc 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/openshift?topic=openshift-cli-install).







 Updating Helm charts 



1.
: Kubernetes [1.16.3_1521](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog1163_1521), [1.15.6_1528](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog1156_1528), [1.14.9_1544](https://cloud.ibm.com/docs/containers?topic=containers-114_changelog1149_1544), and [1.13.12_1547](https://cloud.ibm.com/docs/containers?topic=containers-113_changelog11312_1547)







 December 2019 



 18 December 2019 

Ingress ALB change log
: Updated the [nginx-ingress image build to 615 and the ingress-auth image to build 372](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog).





 17 December 2019 

Version change log
: Master patch updates are available.
: Kubernetes [1.16.3_1520](https://cloud.ibm.com/docs/containers?topic=containers-116_changelog1163_1520), [1.15.6_1527](https://cloud.ibm.com/docs/containers?topic=containers-115_changelog1156_1527), [1.14.9_1543](https://cloud.ibm.com/docs/containers?topic=containers-114_changelog1149_1543), and [1.13.12_1546](https://cloud.ibm.com/docs/containers?topic=containers-113_changelog11312_1546)

Adding classic infrastructure servers to gateway-enabled clusters
: Adding classic IBM Cloud infrastructure server instances to your cluster network is now generally available for classic gateway-enabled clusters.

Assigning access
[Create a new Kubernetes cluster](https://cloud.ibm.com/kubernetes/catalog/cluster) in Kubernetes Service, under Infrastructure select the new VPC as target, make sure to select the resource group created above.
7. Create a [Virtual Servers for VPC instance](https://cloud.ibm.com/vpc-ext/compute/vs) in the same VPC.
8. From the Kubernetes cluster connect to the IBM Log Analysis and IBM Cloud Monitoring service instances to send logs and to monitor the cluster.



The following diagram shows where the project resources are created under the account:

Zoom

![Diagram showing the project resources](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution20-users-teams-applications/resource-deployment.svg)

Project resources





 Assign roles within the environment 



1. Invite users to the account.
2. Assign Policies to the users to control who can access the resource group, the services within the group and the Kubernetes Service instance and their permissions. Refer to the [access policy definition](https://cloud.ibm.com/docs/containers?topic=containers-usersaccess_policies) to select the right policies for a user in the environment. Users with the same set of policies can be placed into the [same access group](https://cloud.ibm.com/docs/account?topic=account-groupsgroups). It simplifies the user management as policies will be assigned to the access group and inherited by all users in the group.



Usually, you can invite team members to the account as users. You could also leverage [trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile) to map federated users to your defined roles (see above).
To interact with your project from the Kubernetes command-line interface, kubectl, or with Knative, kn you must set up your environment to interact with the Kubernetes API of Code Engine.

Before you begin



* You must [create your project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project) and the project must be in active status.
* Install the [Kubernetes CLI (kubectl)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-kubernetesknative-kubectl) and the [Knative CLI (kn)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-kubernetesknative-kubectl).



You can set up your environment in the following ways.



* You can add the --kubecfg option to your project select command. For example,

ibmcloud ce project select --name PROJECT_NAME --kubecfg
* You can export the kubeconfig file directly. Run the ibmcloud ce project current command to find the project that you are currently targeting. This command also returns the export command for your kubeconfig file. For example,

ibmcloud ce project current

Example output

Getting the current project context...
OK

Name: myproject
ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Subdomain: aabon2dfwa0
Domain: us-south.codeengine.appdomain.cloud
Region: us-south
Kubectl Context: 4svg40kna19

Kubernetes Config:
Context: aabon2dfwa0
: Kubernetes [1.22.6_1538](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1221226_1538), [1.21.9_1548](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1211219_1548), [1.20.15_1569](https://cloud.ibm.com/docs/containers?topic=containers-changelog_12012015_1569), [1.19.16_1576](https://cloud.ibm.com/docs/containers?topic=containers-changelog_11911916_1576).

New! Worker node flavor reference
: View a list of all available worker node flavors by zone. For more information, see [VPC Gen 2 flavors](https://cloud.ibm.com/docs/containers?topic=containers-classic-flavors) or [Classic flavors](https://cloud.ibm.com/docs/containers?topic=containers-vpc-flavors).





 27 January 2022 

Block Storage for VPC add-on.
: [Version 4.1.2_834](https://cloud.ibm.com/docs/containers?topic=containers-vpc_bs_changelog) is released.

New! Gathering Ingress logs
: When troubleshooting Ingress, follow the steps in [gathering Ingress logs](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-must-gather) to retrieve useful debugging information.





 26 January 2022 

ALB OAuth Proxy add-on
: Versions 1.0.0_924 and 2.0.0_923 of the [ALB OAuth Proxy add-on](https://cloud.ibm.com/docs/containers?topic=containers-alb-oauth-proxy-changelog) are released.





 25 January 2022 

Kubernetes Ingress image
Overview of use cases 

Various use cases show the strengths of IBM Cloud Kubernetes Service and IBM Cloud services when used together. These stories highlight several industries as well as types of workloads. Even though each use case is presented through the lens of a particular industry, these workloads are typical across various industries. You see workload themes, such as:



* AI and machine learning
* Data and storage
* DevOps
* Identity management



Financial services
: Trim IT costs and [accelerate regulatory compliance](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_financeuc_mortgage)
: Streamline developer productivity to deploy AI tools to partners [4 times faster](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_financeuc_payment_tech).

Government
: Secure the exchange of data, [connecting public and private organizations](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_port).
: Improve collaboration velocity with community Developers, [combining public-private data](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_govuc_data_mashup).

Healthcare
: Migrate workloads from inefficient VMs to [easily operated containers for patient systems](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_healthuc_migrate).
: Securely host sensitive data while you [grow research with partners](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_healthuc_research).

Retail
: Share data via APIs with global business partners to [drive omnichannel sales](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_retailuc_data-share).
: Optimize inventory expenses with [digital insights to sales behavior](https://cloud.ibm.com/docs/containers?topic=containers-cs_uc_retailuc_grocer).
Iter8 is the release engineering tool for Kubernetes that enables service-level objectives (SLO) validation, A/B testing, and progressive updates for Kubernetes applications. Now, you can use Iter8 to verify that your IBM Cloud® Code Engine application is running with low latency and is error-free. Learn more about Iter8 in 5 minutes.

Code Engine



* 5 minutes
* 2023-02-21



[Sending GitHub events to an application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-github-event-webhooks)Sending GitHub events to an application

You can set up a webhook to send a GitHub event, such as a new issue or a commit to your IBM Cloud® Code Engine application. Your application must use a public endpoint to receive the webhook POST requests.

Code Engine



* 10 minutes
* 2023-02-23



[Getting started with your migration from Heroku to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-heroku-migrate)Getting started with your migration from Heroku to Code Engine

Welcome Heroku users to IBM Cloud® Code Engine.

Code Engine



* 10 minutes
* 2023-02-21



[Deploying your application code from a local source ](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-local)Deploying your application code from a local source

Let's deploy a simple hello world app to see how Code Engine works. Follow the steps to create a project, prepare your code, and deploy your app.

Code Engine



* 10 minutes
* 2022-12-07



[Deploying Cloud Foundry applications in Code Engine: Getting started ](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-tutorial)Deploying Cloud Foundry applications in Code Engine: Getting started

Welcome Cloud Foundry users to IBM Cloud® Code Engine.

Code Engine



* 30 minutes
[private](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloadsapp-endpoint-private) An app with this setting is exposed to the IBM Cloud private network and your Code Engine project. Setting a private endpoint means that your app is not accessible from the public internet and network access is only possible from other IBM Cloud services by using Virtual Private Endpoints (VPE) or Code Engine components that are running in the same project. 



You can set the endpoint settings for visibility of an application from the console or with the CLI when you create and deploy, or update your app.



 Deploying your app with a public endpoint 

When you deploy an app, by default, the application deploys such that it can receive requests from the public internet or from components within the same Code Engine project. In this case, the app is deployed with a public endpoint.





 Deploying your app with a private endpoint 

You can set the endpoint visibility for your app such that it is deployed with a private endpoint. Setting a private endpoint means that your app is not accessible from the public internet and network access is only possible from other IBM Cloud services from virtual private endpoints (VPE) or Code Engine components that are running in the same project (cluster-local).

For example, if your solution consists of a component that is running on an IBM Cloud Kubernetes Service Kubernetes cluster within your own virtual private endpoint and you want to access the Code Engine application from the IBM Cloud private network, you can set the visibility of the application to private. When the visibility of the app is set to private, the app is not accessible through the public internet. The application is still accessible from other applications within the project.

You can [deploy your application with a private endpoint](https://cloud.ibm.com/docs/codeengine?topic=codeengine-vpeusing-vpes-app) so that the app is only exposed through the IBM Cloud private network and not exposed to the external internet. The application is still reachable through shared components from within the internal network and the application endpoint needs to be secured.
Containerized apps with Ingress 

With IBM Cloud® App ID, you can consistently enforce policy-driven security by using the Ingress networking capability in IBM Cloud Kubernetes Service. With this approach, you can enforce authentication and authorization policies for all the applications in your cluster at the same time, without ever changing your app code!

The Kubernetes Service custom Ingress image is deprecated as of 01 December 2020. This tutorial is updated to use the community Kubernetes Ingress image. To see the previous version of this documentation, see the [Kubernetes Service documentation](https://cloud.ibm.com/docs/containers?topic=containers-comm-ingress-annotationsapp-id-authentication).

Zoom

![App ID Kubernetes integration architecture](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/kube-integration.png)

Figure 1. App ID Kubernetes integration architecture



1. A user opens your application and triggers a request to the web app or API.
2. In the API flow, the Ingress controller attempts to validate the supplied tokens. If the web flow is used, it starts a three-leg OIDC authentication process.
3. App ID begins the authentication process by displaying the login widget.
4. The user provides a username or email and password.
5. The Ingress controller obtains access and identity tokens from App ID for authorization.
6. Every request that is validated and forwarded by the Ingress controller to your apps has an authorization header that contains the tokens.





 Before you begin 

Before you can get started, ensure that you have the following prerequisites.



* An instance of App ID that is provisioned in the same region in which your cluster is deployed. The service name must contain only alphanumeric characters or hyphens (-), and cannot contain spaces.
Component Previous Current Description 

 IBM Cloud Provider v1.11.2-71 v1.11.3-91 Updated to support Kubernetes 1.11.3 release. 
 IBM file storage classes N/A N/A Removed mountOptions in the IBM file storage classes to use the default that is provided by the worker node. <br>Also, now when you update the cluster master, the default IBM file storage class remains ibmc-file-bronze. 
 Key Management Service Provider N/A N/A Added the ability to use the Kubernetes [key management service (KMS) provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect) in the cluster, to support IBM® Key Protect for IBM Cloud®. When you [enable Key Protect or a key management service (KMS) provider in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect), all your Kubernetes secrets are encrypted. 
 Kubernetes v1.11.2 v1.11.3 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.11.3). 
 Kubernetes DNS autoscaler 1.1.2-r2 1.2.0 See the [Kubernetes DNS autoscaler release notes](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler/releases/tag/1.2.0). 
 Log rotate N/A N/A Switched to use systemd timers instead of cronjobs to prevent logrotate from failing on worker nodes that are not reloaded or updated within 90 days. Note: In all earlier versions for this minor release, the primary disk fills up after the cron job fails because the logs are not rotated. The cron job fails after the worker node is active for 90 days without being updated or reloaded. If the logs fill up the entire primary disk, the worker node enters a failed state.