vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Deploying Kubernetes-native apps in clusters 

You can use Kubernetes techniques in IBM Cloud® Kubernetes Service to deploy apps in containers and ensure that those apps are up and running. For example, you can perform rolling updates and rollbacks without downtime for your users.

For more information about creating a configuration file for your application, see [Configuration Best Practices](https://kubernetes.io/docs/concepts/configuration/overview/).

Zoom

![Basic deployment process.](https://cloud.ibm.com/docs-content/v1/content/4d497aff9e27b92fbbc2ee4e343a9ec4549cb1d7/containers/images/basic_app_deployment_process.png)

Figure 1. Basic deployment process



 Launching the Kubernetes dashboard 

Open a Kubernetes dashboard on your local system to view information about a cluster and its worker nodes. [In the IBM Cloud console](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appdb_gui), you can access the dashboard with a convenient one-click button. [With the CLI](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appdb_cli), you can access the dashboard or use the steps in an automation process such as for a CI/CD pipeline.

Do you have so many resources and users in your cluster that the Kubernetes dashboard is a little slow? Your cluster admin can scale the kubernetes-dashboard deployment by running kubectl -n kube-system scale deploy kubernetes-dashboard --replicas=3.

To check the logs for individual app pods, you can run kubectl logs <pod name>. Do not use the Kubernetes dashboard to stream logs for your pods, which might cause a disruption in your access to the Kubernetes dashboard.

Before you begin
[ref architecture icon](https://cloud.ibm.com/media/docs/images/homepage/reference-architecture.svg) [Resilient and secure multi-region Kubernetes clusters with IBM Cloud Internet Services](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-multi-region-k8s-cis)Resilient and secure multi-region Kubernetes clusters with IBM Cloud Internet Services Solution tutorial

This tutorial highlights how Cloud Internet Services (CIS), a uniform platform to configure and manage the Domain Name System (DNS), Global Load Balancing (GLB), Web Application Firewall (WAF), and protection against Distributed Denial of Service (DDoS) for internet applications, can be integrated with Kubernetes clusters to support this scenario and to deliver a secure and resilient solution across multiple locations.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Resource sharing across accounts](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-resource-sharing)Resource sharing across accounts Solution tutorial

This tutorial walks you through different options on how to share cloud-based resources across accounts.

![solution tutorial icon](https://cloud.ibm.com/media/docs/images/homepage/solution-tutorial.svg) [Scalable web application on Kubernetes](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-scalable-webapp-kubernetes)Scalable web application on Kubernetes Solution tutorial

This tutorial walks you through how to run a web application locally in a container, and then deploy it to a Kubernetes cluster created with Kubernetes Service. As an optional step you can build a container image and push the image to a private registry. Additionally, you will learn how to bind a custom subdomain, monitor the health of the environment, and scale the application.

!
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/efbf7b33e3aca029f69f9244bced9dd4d8acb848/apps/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)
* Storage: Choose the storage plan that works for your needs. See [Understanding Kubernetes storage basics](https://cloud.ibm.com/docs/containers?topic=containers-kube_conceptskube_concepts) to learn more about your storage class options and how much they [cost](https://www.ibm.com/cloud/file-storage/pricing). The IBM Blockchain Platform nodes use the default storage class for the cluster. When you provision a Kubernetes cluster in IBM Cloud, it is preconfigured with [Gold File storage](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile_predefined_storageclass) as the persistent storage plug-in.
* Advanced features: Options that are available for Production networks for increased security, disaster recovery, and health monitoring of the nodes. Costs vary depending on the options you choose.



When you allocate VPCs (or CPU) to a blockchain node, the node consumes CPUs from your Kubernetes cluster allocation. Therefore the size of the Kubernetes cluster that is required directly depends on the size and quantity of the blockchain nodes that you deploy.





 Pricing examples 

The following table provides two examples of pricing with [default resource allocations](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-saas-pricingibp-saas-pricing-default) unless otherwise noted. Both examples assume an IBM Cloud Kubernetes service cluster and the default CouchDB database is used as the peer database. It also assumes peers are deployed with Fabric v2.x images instead of Fabric v1.4 images.



* The Test network scenario is suitable for getting started with your first use case with IBM Blockchain and testing smart contracts.
* The Join a network scenario includes two peers, and a Certificate Authority (CA) that is required for organization membership.



* These peers can join a production IBM Blockchain Platform network that is hosted elsewhere.
Setting Kubernetes API priority and fairness 

Your IBM Cloud® Kubernetes Service clusters have default settings in place to process simultaneous requests to the API server and prevent traffic overload. You can configure your own flow schema and priority levels for requests that are made to the API server of your clusters. For more information, see [API priority and fairness](https://kubernetes.io/docs/concepts/cluster-administration/flow-control/) in the Kubernetes documentation.

For example, you might have a user or namespace that runs your critical apps in prod. You can create a flow schema and priority so that your critical apps have a higher priority for the API server to fulfill their requests than other apps in the cluster.



 Reviewing default flow schema and priority levels 

IBM Cloud Kubernetes Service sets certain default flow schema and priority levels in addition to the default settings from Kubernetes.



Default flow schema and priority levels

 Flow schema Resources that requests come from Priority level 

 apiserver-health Kubernetes API server health resources [Custom priority level](https://cloud.ibm.com/docs/containers?topic=containers-kubeapi-prioritykube-api-prioritylevelconfig) for these resources. 
 ibm-admin Resources from IBM cluster administrators Exempts requests by cluster administrators from priority restrictions 
 ibm-system-service-accounts Resources in the ibm-system namespace that use a service account in the namespace Same priority as kube-system namespace service accounts 
 ibm-operators-service-accounts Resources in the ibm-operators namespace that use a service account in the namespace Same priority as kube-system namespace service accounts 
 system-node-proxiers The kube-proxy Same priority as the kubelet 



You can create your own flow schema and priorities, but don't modify the default settings. Unexpected results might occur in your cluster when you modify API request priorities.

Follow the steps to review the flow schemas and priority levels set by IBM Cloud Kubernetes Service.



1. List all flow schemas in your cluster, including those set by IBM Cloud Kubernetes Service, and their corresponding priority levels .
Deploying apps to clusters with Continuous Delivery and Satellite Config 

Deploy Kubernetes resources, like deployments, from your GitHub or GitLab repository to multiple clusters with IBM Cloud® Continuous Delivery and Satellite Config.



 Objectives 

In this tutorial, you learn how to create an open toolchain by using Continuous Delivery to deploy your app to multiple clusters. You also learn how toolchains are implemented in the Continuous Delivery service and how to deploy a simple web app by using a Continuous Delivery-only toolchain template.

With Satellite Config, you create a configuration that specifies which Kubernetes resources you want to deploy to a cluster group. Then, set up a Continuous Delivery pipeline to deploy these resources across a group of clusters whenever a change is made to the configuration.

The toolchain that is used in this tutorial implements standard DevOps practices around continuous delivery capabilities by managing your deployments in Satellite locations. After you create clusters and associate them with a Satellite cluster group, you can create a toolchain to change your deployment source code and push the change to the GitHub repo. When you push changes to your repo, the Tekton-based delivery pipeline automatically deploys the code to your clusters.





 Audience 

This tutorial is for administrators who are using Continuous Delivery toolchains and Satellite Config to deploy resources for the first time.





 Prerequisites 

Before you start this tutorial, make sure that you have the following resources in place.



* An [IBM Cloud account](https://cloud.ibm.com/registration). Depending on your IBM Cloud account type, access to certain resources might be limited. Depending on your account plan limits, certain capabilities that are required by some deployment strategies might not be available. For more information about IBM Cloud accounts, see [Setting up your IBM Cloud account](https://cloud.ibm.com/docs/account?topic=account-account-getting-started) and [Upgrading your account](https://cloud.ibm.com/docs/account?topic=account-upgrading-account).
* A Satellite cluster or an Red Hat® OpenShift® cluster on IBM Cloud that is registered with your Satellite location.
On the Create a Toolchain page, click Develop a Kubernetes app.



 Configure the toolchain name and region 

Review the default information for the toolchain settings. The toolchain's name identifies it in IBM Cloud. Make sure that the toolchain's name is unique within your toolchains for the same region and resource group in IBM Cloud.

The toolchain region can differ from the cluster and registry region.

Zoom

![Kubernetes secure app toolchain name and region](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_name_region.png)

Figure 1. Kubernetes secure app toolchain name and region





 Select the deployment strategy 

The toolchain creates a Continuous Deployment Pipeline to deploy the application Docker image on the IBM Cloud® Kubernetes Service. Select the deployment strategy that you want to use. Based on which deployment strategy you choose (Rolling, Blue-Green, or Canary), you must provide more details.



1. Click the deployment strategy that you want to use for your toolchain.

Zoom

![Kubernetes secure app deployment strategies](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/ds_kub_setup_ds-selection_rolling.png)

Figure 2. Deployment strategies
2. Click Continue.







 Configure the application source code repo 

In the Application step, that recommended options for the application source code repo are displayed by default. To view all of the available options for the underlying Git integration, click Advanced Options. By default, the toolchain uses the default sample that clones the sample app as an IBM-hosted Git Repos and Issue Tracking repo.
* Create clusters for public-private apps, which are driven by the APIs.
* Structure apps into a set of cooperative microservices that run within IBM Cloud Kubernetes Service, which is based on functional areas of apps and their dependencies.
* Deploy the apps to containers that run in IBM Cloud Kubernetes Service. Built-in HA tools in IBM Cloud Kubernetes Service balance the workloads, including self-healing and load balancing.
* Provide standardized DevOps dashboards through Kubernetes, open-source tools familiar to all types of Developers.







 Step 3: Innovate with IBM Garage and cloud services 



* Adopt the agile and iterative development practices from the IBM Garage Method to enable frequent releases of features, patches, and fixes without downtime.
* Whether developers are in the public or private sector, IBM Cloud® Continuous Delivery helps them to quickly provision an integrated toolchain, by using customizable, shareable templates.
* After Developers build and test the apps in their Dev and Test clusters, they use the IBM Cloud® Continuous Delivery toolchains to deploy apps into production clusters.
* With Watson AI, machine learning, and deep learning tools available from the IBM Cloud catalog, Developers focus on domain problems. Instead of custom unique ML code, ML logic is snapped into apps with service bindings.









 Results 



* Normally slow public-private partnerships now quickly spin up apps in weeks instead of months. These development partnerships now deliver features and bug fixes up to 10 times per week.
* Development is accelerated when all participants use well-known open-source tools, such as Kubernetes. Long learning curves are no longer a blocker.
* Transparency in activities, information, and plans is provided to citizens and private sector. And, citizens are integrated into government processes, services, and support.
* Public-private partnerships conquer Herculean tasks, such as Zika virus tracking, smart electricity distribution, analysis of crime statistics, and university "new collar" education.









 Large public port secures exchange of port data and shipping manifests that connect public and private organizations 

IT Execs for a private shipping company and the government-operated port need to connect, provide visibility, and securely exchange port information.
Default service settings for Kubernetes components 

Review the default settings for Kubernetes components, such as the kube-apiserver, kubelet, kube-scheduler, or kube-proxy that IBM Cloud® Kubernetes Service sets when you create your cluster.



 kube-apiserver 

Review the default settings for the kube-apiserver master component in IBM Cloud Kubernetes Service.

Default pod tolerations
: default-not-ready-toleration-seconds=600s
: default-unreachable-toleration-seconds=600s

Privileged pods
: allow-privileged=true

Request headers
: requestheader-client-ca-file=/mnt/etc/kubernetes-cert/ca.pem
: requestheader-username-headers=X-Remote-User
: requestheader-group-headers=X-Remote-Group
: requestheader-extra-headers-prefix=X-Remote-Extra-

Number of client requests
: max-requests-inflight=1600
: max-mutating-requests-inflight=800

Admission controllers
: ClusterTrustBundleAttest (Kubernetes version 1.27 and later)
: ValidatingAdmissionPolicy (Kubernetes version 1.27 and later)
: DefaultStorageClass
: NamespaceLifecycle
: LimitRanger
: ServiceAccount
: MutatingAdmissionWebhook
: ValidatingAdmissionWebhook
: ResourceQuota
: DefaultTolerationSeconds
: StorageObjectInUseProtection
: PersistentVolumeClaimResize
: Priority
: PodSecurity (Optional in Kubernetes version 1.24, enabled in version 1.25 and later)
: PodSecurityPolicy (Kubernetes version 1.24 and earlier)
: NodeRestriction
: TaintNodesByCondition
: CertificateApproval
: CertificateSigning



* CertificateSubjectRestriction
* DefaultIngressClass
* RuntimeClass
* Kubernetes service integration. Leverage services such as IBM Log Analysis for logging and Prometheus and IBM Cloud Monitoring for monitoring. Leverage the built-in IBM Cloud services, such as IBM Cloud Kubernetes Service and OpenShift dashboards, IBM Log Analysis, and IBM Cloud Identity and Access Management (IAM).
* Upgrade the Fabric version of your nodes. Nodes running Fabric version 1.4.x can be [upgraded to 2.x.](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-govern-componentsibp-console-govern-components-upgrade)



After which, the capabilities of your channels can also be increased to v2.0, allowing full access to the latest Fabric features like the smart contract lifecycle.

GROW --- Scalability and flexibility



* Choose your compute. You have the flexibility to decide the amount of CPU, memory, and storage you want to provision in your Kubernetes cluster. For more information, see [Allocating resources](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-allocate-resources).
* Scale up and down the resources in your Kubernetes cluster, paying for only what you need. For more information, see [Pricing](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-saas-pricing).
* Disaster recovery and multi-region high availability (HA). This option duplicates your Kubernetes deployment across zones and regions, enabling high availability (HA) of your components and disaster recovery (DR).
* Connect to other Fabric networks: Join IBM Blockchain Platform peers to any network running Hyperledger Fabric components. Similarly, you can invite Fabric peers to join channels hosted on an ordering service deployed on the IBM Blockchain Platform. Note that you will need to use Hyperledger Fabric APIs or the CLI.



This offering is intended for experienced Fabric users who want to build and manage their own networks.
If you plan to use a local Cloud Object Storage server or a different s3 API endpoint, create a Kubernetes secret with the appropriate credentials.

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)
* Make sure that you have the Manager service access role for the cluster.



To create a secret for your IBM Cloud Object Storage credentials:



1. Retrieve the apikey, or the access_key_id and the secret_access_key of your [IBM Cloud Object Storage service credentials](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandservice_credentials). Note that the service credentials must be enough for the bucket operations that your app needs to perform. For example, if your app reads data from a bucket, the service credentials you see in your secret must have Reader permissions at minimum. If you want to integrate Key Protect encryption when creating new buckets from PVCs in your cluster, you must to include the root key CRN when creating your [IBM Cloud Object Storage secret](https://cloud.ibm.com/docs/containers?topic=containers-storage-cos-understandcreate_cos_secret). Note that Key Protect encryption can't be added to existing buckets.
2. Get the GUID of your IBM Cloud Object Storage service instance.

ibmcloud resource service-instance <service_name> | grep GUID
3. Create a Kubernetes secret to store your service credentials. When you create your secret, all values are automatically encoded to base64. In the following example, the secret name is cos-write-access.

Example create secret command that uses an API key.

kubectl create secret generic cos-write-access --type=ibm/ibmc-s3fs --from-literal=api-key=<api_key> --from-literal=service-instance-id=<service_instance_guid>
Connecting an IBM Cloud application 

Applications running in IBM Cloud can be bound to your IBM Cloud® Databases for EnterpriseDB deployment.



 Connecting a Kubernetes Service application 

There are two steps to connecting a Cloud databases deployment to a Kubernetes Service application. First, your deployment needs to be bound to your cluster and its connection strings that are stored in a secret. Second, configure your application to use the connection strings.

The sample app in the [Connecting a Kubernetes Service Tutorial](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-tutorial-k8s-app) provides a sample application that uses Node.js and demonstrates how to bind the sample application to a Cloud Databases deployment.

Before connecting your Kubernetes Service application to a deployment, make sure that the deployment and cluster are both in the same region and resource group.



 Binding your deployment 

Public Endpoints - If you are using the default public service endpoint to connect to your deployment, you can run the cluster service bind command with your cluster name, the resource group, and your deployment name.

ibmcloud ks cluster service bind <your_cluster_name> <resource_group> <your_database_deployment>

OR Private Endpoints - If you want to use a private endpoint (if one is enabled on your deployment), then first you need to create a service key for your database so Kubernetes can use it when binding to the database.

ibmcloud resource service-key-create <your-private-key> --instance-name <your_database_deployment> --service-endpoint private

The private service endpoint is selected with --service-endpoint private. After that, you bind the database to the Kubernetes cluster through the private endpoint with the cluster service bind command.

ibmcloud ks cluster service bind <your_cluster_name> <resource_group> <your_database_deployment> --key <your-private-key>

Verify - Verify that the Kubernetes secret was created in your cluster namespace. Running the following command, you get the API key for accessing the instance of your deployment provisioned in your account.