vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Satellite Config <br><br> * Provide a highly available configuration management service that you can use to manage the deployment of Kubernetes resources across clusters that are registered with the location.<br> * Provide an interface to initiate operational activities, such as to create and delete configurations.<br> * Provide a kubectl command that users can run in a Red Hat OpenShift cluster to register the cluster to Satellite Config.<br> * Provide the ability to create Kubernetes resource configurations, upload new versions, and subscribe a subset of cluster to a version, including to a previous version.<br> * Store app configuration files in a highly available, back-end data store (etcd).<br> * Automatically forward configuration events to your IBM Cloud Activity Tracker instance.<br><br><br> <br><br> * Use the provided tools to [set up clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig), upload your Kubernetes configuration file content as versions in the configuration, and subscribe your clusters to the [configuration](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-manage-direct-upload). Keep in mind that you are responsible for the apps that run in your clusters, but you can use Satellite Config to help you consistently deploy and update your apps.<br><br><br>
Adding services by using Helm charts 

You can add complex Kubernetes apps to your cluster by using Helm charts.



 About Helm in IBM Cloud Kubernetes Service 



 What is Helm and how do I use it? 

[Helm](https://helm.sh) is a Kubernetes package manager that uses Helm charts to define, install, and upgrade complex Kubernetes apps in your cluster. Helm charts package the specifications to generate YAML files for Kubernetes resources that build your app. These Kubernetes resources are automatically applied in your cluster and assigned a version by Helm. You can also use Helm to specify and package your own app and let Helm generate the YAML files for your Kubernetes resources.





 What Helm charts are supported in IBM Cloud Kubernetes Service? 

For an overview of available Helm charts, see the [Helm charts catalog](https://cloud.ibm.com/kubernetes/helm). The Helm charts that are listed in this catalog are grouped as follows:



* iks-charts: Helm charts that are approved for IBM Cloud Kubernetes Service. The name of this repo was changed from ibm to iks-charts.
* ibm-charts: Helm charts that are approved for IBM Cloud Kubernetes Service and IBM Cloud Private clusters.
* ibm-community: Helm charts that originated outside IBM, such as from [IBM Cloud Kubernetes Service partners](https://cloud.ibm.com/docs/containers?topic=containers-service-partners). These charts are supported and maintained by the community partners.
* kubernetes: Helm charts that are provided by the Kubernetes community and considered stable by the community governance. These charts are not verified to work in IBM Cloud Kubernetes Service or IBM Cloud Private clusters.
* kubernetes-incubator: Helm charts that are provided by the Kubernetes community and considered incubator by the community governance. These charts are not verified to work in IBM Cloud Kubernetes Service or IBM Cloud Private clusters.
* entitled: Helm charts of licensed software that you must purchase and for which you must set up cluster access with an entitlement key.
Configuring the cluster DNS provider 

Each service in your IBM Cloud® Kubernetes Service cluster is assigned a Domain Name System (DNS) name that the cluster DNS provider registers to resolve DNS requests. For more information about DNS for services and pods, see [the Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/).

The cluster DNS provider is [CoreDNS](https://coredns.io/), which is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. Because CoreDNS is a single executable and single process, it has fewer dependencies and moving parts that could experience issues than other cluster DNS providers. The project is also written in the same language as the Kubernetes project, Go, which helps protect memory. Finally, CoreDNS supports more flexible use cases than other cluster DNS providers because you can create custom DNS entries such as the common setups in [the CoreDNS docs](https://coredns.io/manual/toc/setups).



 Autoscaling the cluster DNS provider 

By default, CoreDNS includes a deployment to autoscale the CoreDNS pods in response to the number of worker nodes and cores within the cluster. You can fine-tune the CoreDNS autoscaler parameters by editing the CoreDNS autoscaling ConfigMap. For example, if your apps heavily use the cluster DNS provider, you might need to increase the minimum number of CoreDNS pods to support the app. For more information, see [the Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/dns-horizontal-autoscaling/).

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.
ibm-storage-cos Set up Helm in an IBM Cloud Kubernetes Service cluster to install the IBM Cloud Object Storage Helm plug-in. Then, you create an IBM Cloud Object Storage service instance where you can store data from the apps in your cluster. You also learn how to create a Kubernetes persistent volume claim (PVC) to create a bucket in your IBM Cloud Object Storage instance. Also to deploy an app in the cluster that mounts your IBM Cloud Object Storage bucket. <br> <br>Resources <br><br><br><br> * ibm_resource_instance<br> * ibm_container_bind_service<br> * kubernetes_secret<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-storage-cos) 
 ibm-openshift-job Create and execute a secured shell script in an Red Hat OpenShift on IBM Cloud cluster by using an Terraform on IBM Cloud template. This template creates a Kubernetes configmap that includes a reference to a shell script. Then, you create a pod that mounts the configmap as a volume and executes the shell script. <br> <br>Resources <br><br><br><br> * kubernetes_secret<br> * kubernetes_config_map<br> * kubernetes_job<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-openshift-job) 
 portworx Set up Helm in an IBM Cloud Kubernetes Service software-defined storage (SDS) cluster to install Portworx as a storage solution. Make sure that this template requires an SDS cluster on Bare Metal worker nodes. After you installed Portworx, you can create persistent volume claims (PVC) to store data on local storage of your worker nodes.
Continuous Deployment to Kubernetes 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

This tutorial walks you through the process setting up a continuous integration and delivery pipeline for containerized applications running on the Kubernetes Service. You will learn how to set up source control, then build, test and deploy the code to different deployment stages. Next, you will add integrations to other services like Slack notifications.



 Objectives 



* Create development and production Kubernetes clusters.
* Create a sample application, run it locally and push it to a Git repository.
* Configure the DevOps delivery pipeline to connect to your Git repository, build and deploy the sample app to dev/prod environments.
* Explore and integrate the app to use Slack notifications.



Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/includes/solution-tutorials/includes/solution-tutorials/images/solution21/Architecture.png)

Figure 1. Architecture diagram of the tutorial



1. The code is pushed to a private Git repository.
2. The pipeline picks up changes in Git and builds container image.
3. The container image is uploaded to registry. The app is deployed to the Development environment.
4. Once changes are validated, the app is deployed to the Production environment.
5. Notifications are sent to Slack to track the deployment activities.







 Before you begin 

This tutorial requires:



* [set up a registry namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup)
Understand the [basics of Kubernetes service discovery](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployservice_discovery).
2. [Choose an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning) that fits your requirements for incoming traffic to the app.



2. Expose your app:



* Load balancers:



* Classic clusters:



1. Create an [NLB 1.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer) or [NLB 2.0](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-v2).
2. [Register a DNS subdomain](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer_hostnameloadbalancer_hostname) for the NLB.



* VPC clusters: Set up a [VPC load balancer](https://cloud.ibm.com/docs/containers?topic=containers-vpc-lbaas).



* Ingress: [Configure Ingress](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-setup) for the public or private network.





Need help? Check out [Troubleshooting Ingress](https://cloud.ibm.com/docs/containers?topic=containers-ingress-debug) and [Troubleshooting load balancers](https://cloud.ibm.com/docs/containers?topic=containers-cs_loadbalancer_fails).





 Add app storage 



1. Storage basics: Start by understanding the [basics of Kubernetes storage](https://cloud.ibm.com/docs/containers?topic=containers-kube_concepts).
2.
Developing Kubernetes-native apps 

Develop a configuration to deploy your app workload to IBM Cloud® Kubernetes Service. Because Kubernetes is an extensible container orchestration platform that does not mandate a specific language or app, you can run various workloads such as stateless, stateful, and data-processing apps that are written in the language of your choice.



 Specifying your app requirements in your YAML file 

In Kubernetes, you describe your app in a YAML file that declares the configuration of the Kubernetes object. The Kubernetes API server then processes the YAML file and stores the configuration and required state of the object in the etcd data store. The Kubernetes scheduler schedules your workloads onto the worker nodes within your cluster, taking into account the specification in your YAML file, any cluster policies that the admin sets, and available cluster capacity.

Review a copy of the [complete YAML file](https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/deploy_wasliberty.yaml). Then, review the following sections to understand how you can enhance your app deployment.

Want more information about how Kubernetes objects work together for your deployment? Check out [Understanding Kubernetes objects for apps](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploykube-objects).



 Basic deployment metadata 

Use the appropriate API version for the [kind of Kubernetes object](https://cloud.ibm.com/docs/containers?topic=containers-plan_deployobject) that you deploy. The API version determines the supported features for the Kubernetes object that are available to you. The name that you give in the metadata is the object's name, not its label. You use the name when interacting with your object, such as kubectl get deployment <name>.

apiVersion: apps/v1
kind: Deployment
metadata:
name: wasliberty





 Replica set 

To increase the availability of your app, you can specify a replica set in your deployment.
The application runs in a Kubernetes cluster from an image stored in the Container Registry.
3. The user will configure IBM Log Analysis service agent to access application and cluster-level logs.
4. The user will configure IBM Cloud Monitoring service agent to monitor the health and performance of the IBM Cloud Kubernetes Service cluster and also the app deployed to the cluster.







 Before you begin 

This tutorial requires:



* IBM Cloud CLI,



* IBM Cloud Kubernetes Service plugin (kubernetes-service),
* Container Registry plugin (container-registry),



* kubectl to interact with Kubernetes clusters,
* git to clone source code repository.



You will find instructions to download and install these tools for your operating environment in the [Getting started with solution tutorials](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorials) guide.

To avoid the installation of these tools you can use the [Cloud Shell](https://cloud.ibm.com/shell) from the IBM Cloud console.

In addition, make sure you:



* [grant permissions to a user to view logs](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-work_iamuser_logdna)





* and [grant permissions to a user to view monitoring metrics](https://cloud.ibm.com/docs/monitoring?topic=monitoring-iamiam_users)







 Step 1: Create a Kubernetes cluster 

Kubernetes Service provides an environment to deploy highly available containerized applications that run in Kubernetes clusters.

A minimal cluster with one (1) zone, one (1) worker node and the smallest available size (Flavor) is sufficient for this tutorial. The name mycluster will be used in this tutorial.

Open the [Kubernetes clusters](https://cloud.ibm.com/kubernetes/clusters) and click Create cluster. See the documentation referenced below for more details based on the cluster type. Summary:



* Click Standard tier cluster
Logging with Kubernetes clusters 

Use the IBM Log Analysis service to configure cluster-level logging in IBM Cloud® Kubernetes Service.

From the moment you provision a cluster with IBM Cloud Kubernetes Service, you want to know what is happening inside the cluster. You need to access logs to troubleshoot problems and pre-empt issues. At any time, you want to have access to different types of logs such as worker logs, pod logs, app logs, or network logs. In addition, you want to monitor different sources of log data in your Kubernetes cluster. Therefore, your ability to manage and access log records from any of these sources is critical. Your success managing and monitoring logs depends on how you configure the logging capabilities for your Kubernetes platform.

To configure cluster-level logging for a Kubernetes cluster, consider the following information:



* You must be able to store log data, system logs, and containerized application logs on separate storage from Kubernetes system components.
* You must deploy a logging agent to every worker node in your cluster. This agent collects and forwards logs to an external logging back-end.
* You must be able to centralize log data for analysis on an external logging back-end.



On 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 on the IBM Cloud Kubernetes Service. Kubernetes v1.9+ clusters are supported.
3. Configure the logging agent on every worker (node) in a cluster.



!
See this [information](https://cloud.ibm.com/docs/containers?topic=containers-responsibilities_iks) for details on what IBM Cloud manages and what you are responsible for.
* You are also responsible for monitoring the resource usage of your Kubernetes cluster on IBM Cloud. To monitor your Kubernetes resources, we recommend using the [IBM Cloud Monitoring](https://www.ibm.com/cloud/cloud-monitoring) tool in combination with your IBM Cloud Kubernetes dashboard. If you need to increase storage capacity or performance of your cluster, see this information on how to [modify your existing volume](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_change_storage_configuration).
* You are responsible for managing and securing your certificates and private keys. IBM does not store your certificates in the Kubernetes cluster or in the console. They are only kept in the local storage of your browser. If you switch browsers, you will have to import your created identities into that browser.
* IBM Blockchain Platform is available in select regions. Refer to this topic on [IBM Blockchain Platform locations](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-regions-locations) for an updated list.
* The default storage that is pre-selected for you when you provision a Kubernetes cluster in IBM Cloud is Gold. If you do not want to use the default File Storage that is pre-selected for you when you provision a Kubernetes cluster in IBM Cloud, you can provision storage of your choice. See this topic on [Persistent storage considerations](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-deploy-iksibp-console-storage) to learn more.
* If you decide to include IBM Cloud multi-zone support in your Kubernetes cluster on IBM Cloud, you must provision your own storage.
Enhance cluster capabilities by integrating various external services and catalog services with your Kubernetes cluster.



1. Review supported integrations:



* [All supported integrations](https://cloud.ibm.com/docs/containers?topic=containers-supported_integrations)
* [Red Hat OpenShift on IBM Cloud partners](https://cloud.ibm.com/docs/openshift?topic=openshift-service-partners)
* [IBM Cloud services and third-party integrations](https://cloud.ibm.com/docs/openshift?topic=openshift-ibm-3rd-party-integrations)



2. Add services to your cluster:



* [Adding Cloud Paks](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_cloud_paks)
* [Adding services by using Operators](https://cloud.ibm.com/docs/openshift?topic=openshift-operators)
* [Adding services by using IBM Cloud service binding](https://cloud.ibm.com/docs/openshift?topic=openshift-service-binding)





Need help? Check out [Troubleshooting apps and integrations](https://cloud.ibm.com/docs/openshift?topic=openshift-debug_worker_nodes).





 Manage the lifecycle 

Manage your cluster and worker nodes through each phase of the cluster lifecycle.



* Autoscaling: [Automatically increase or decrease the number of worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-classic-vpc) based on the sizing needs of your scheduled workloads.
* Updating: Keep your environment up-to-date by frequently [updating clusters, worker nodes, and cluster components](https://cloud.ibm.com/docs/containers?topic=containers-update). While you update, refer to these version reference pages:
Verify that the kubectl commands run properly with your cluster by checking the Kubernetes CLI server version.

kubectl version --short

Example output

Client Version: 1.26
Server Version: 1.26+IKS









 Step 2: Deploy a privately available app 

Create a Kubernetes deployment to deploy a single app instance as a pod to your worker node in your VPC cluster.



1. Clone the source code for the [Hello world app](https://github.com/IBM/container-service-getting-started-wt) to your user home directory. The repository contains different versions of a similar app in folders that each start with Lab. Each version contains the following files:



* Dockerfile: The build definitions for the image.
* app.js: The Hello world app.
* package.json: Metadata about the app.



git clone https://github.com/IBM/container-service-getting-started-wt.git
2. Go to the Lab 1 directory.

cd 'container-service-getting-started-wt/Lab 1'
3. Use an existing registry namespace or create one, such as vpc-gen2.

ibmcloud cr namespace-list

ibmcloud cr namespace-add vpc-gen2
4. Build a Docker image that includes the app files of the Lab 1 directory, and push the image to the IBM Cloud Container Registry namespace that you created. If you need to change the app in the future, repeat these steps to create another version of the image. Note: Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with container images.

Use lowercase alphanumeric characters or underscores (_) only in the image name. Don't forget the period (.) at the end of the command. The period tells Docker to look inside the current directory for the Dockerfile and build artifacts to build the image.
Continuous Deployment to Kubernetes 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

This tutorial walks you through the process setting up a continuous integration and delivery pipeline for containerized applications running on the Kubernetes Service. You will learn how to set up source control, then build, test and deploy the code to different deployment stages. Next, you will add integrations to other services like Slack notifications.



 Objectives 



* Create development and production Kubernetes clusters.
* Create a sample application, run it locally and push it to a Git repository.
* Configure the DevOps delivery pipeline to connect to your Git repository, build and deploy the sample app to dev/prod environments.
* Explore and integrate the app to use Slack notifications.



Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution21/Architecture.png)

Figure 1. Architecture diagram of the tutorial



1. The code is pushed to a private Git repository.
2. The pipeline picks up changes in Git and builds container image.
3. The container image is uploaded to registry. The app is deployed to the Development environment.
4. Once changes are validated, the app is deployed to the Production environment.
5. Notifications are sent to Slack to track the deployment activities.







 Before you begin 

This tutorial requires:



* [set up a registry namespace](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_setup_cli_namespaceregistry_namespace_setup)
* and [understand the basics of Kubernetes](https://kubernetes.io/docs/tutorials/kubernetes-basics/).
Secure secrets for apps that run in your Kubernetes cluster 

In this tutorial, you learn how to use IBM Cloud® Secrets Manager to manage secrets for applications that run your IBM Cloud Kubernetes Service cluster by using the [External Secrets Operator](https://external-secrets.io/latest/) open-source tool.

Alternatively, you can use the Kubernetes Service CLI plug-in to manage TLS and non-TLS secrets. To learn more about this approach, see [Setting up Kubernetes Ingress](https://cloud.ibm.com/docs/containers?topic=containers-secrets-mgr).

This tutorial is for the Classic flavor of Kubernetes Service clusters. External Secrets is also available as an [OpenShift operator](https://operatorhub.io/operator/external-secrets-operator).

You're a developer for a large organization, and your team is using Kubernetes Service to deploy containerized apps and services on IBM Cloud. In your current flow, you use [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) to store the sensitive data, such as passwords and API keys, that are used by the apps and services that run in your cluster. To have more control over your application secrets, you want the ability to store your cluster secrets in an external secrets management service, where you can [encrypt them at rest](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-mng-data), [monitor their activity](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-at-events), and easily manage them.

With Secrets Manager, you can centralize and secure the secrets that are used by the apps that run in your Kubernetes clusters. Rather than injecting your secrets at deployment time, you can configure your apps to securely retrieve secrets from Secrets Manager at run time. When it's time to rotate the secret, you can do so from Secrets Manager. For example, consider the following scenario:

Zoom

!