vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Understanding Kubernetes storage basics 

Before you get started with provisioning storage, it is important to understand the Kubernetes concepts for storage, dynamic provisioning, static provisioning, as well as the storage classes that are available to you.



 Persistent volumes and persistent volume claims 

Before you get started with provisioning storage, it is important to understand the Kubernetes concepts of a persistent volume and a persistent volume claim and how they work together in a cluster.

The following image shows the storage components in a cluster.

Zoom

![Storage components in a cluster.](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_storage_pvc_pv.svg)

Figure 1. Storage components in a cluster

Cluster
: By default, every cluster is set up with a plug-in to [provision file storage](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storageadd_file). You can choose to install other add-ons, such as the one for [block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storage). To use storage in a cluster, you must create a persistent volume claim, a persistent volume and a physical storage instance. When you delete the cluster, you have the option to delete related storage instances.

App
: To read from and write to your storage instance, you must mount the persistent volume claim (PVC) to your app. Different storage types have different read-write rules. For example, you can mount multiple pods to the same PVC for file storage. Block storage comes with a RWO (ReadWriteOnce) access mode so that you can mount the storage to one pod only.

Persistent volume claim (PVC)
: A PVC is the request to provision persistent storage with a specific type and configuration.
[Diagram of a modern container architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution30/modern_architecture.png)

Diagram of a modern container architecture



1. The user sends a request to the public endpoint of the app. The public endpoint is represented by an Ingress application load balancer (ALB) that load balances incoming network traffic across app pods in the cluster. The ALB is a collection of rules that allow inbound network traffic to a publicly exposed app.
2. The ALB forwards the request to one of the available app pods in the cluster. App pods run on worker nodes that can be a virtual or physical machine.
3. App pods store data in persistent volumes. Persistent volumes can be used to share data between app instances or worker nodes.
4. App pods store data in an IBM Cloud database service. You can run your own database inside the Kubernetes cluster, but using a managed database-as-a-service (DBaaS) is usually easier to configure and provides built-in backups and scaling. You can find many different types of databases in the [IBM Cloud catalog](https://cloud.ibm.com/catalog?category=databasesservices).







 VMs, containers, and Kubernetes 

Kubernetes Service provides the capability to run containerized apps in Kubernetes clusters and delivers the following tools and functions:



* Intuitive user experience and powerful tools.
* Built-in security and isolation to enable rapid delivery of secure applications.
* Cloud services that include cognitive capabilities from IBM® Watson™.
* Ability to manage dedicated cluster resources for both stateless applications and stateful workloads.





 Virtual machines vs containers 

VMs, traditional apps run on native hardware. A single app does not typically use the full resources of a single compute host. Most organizations try to run multiple apps on a single compute host to avoid wasting resources.
* [Features and limitations of KMS providers](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms-keyprotect-features)



* [Encrypting the Kubernetes secrets by using a KMS provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect)



* [Prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms_prereqs)
* [Enabling KMS encryption for the cluster through the CLI](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms_cli)
* [Enabling KMS encryption for the cluster through the console](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms_ui)
* [Rotating the root key for your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkms_rotate)



* [Verifying secret encryption](https://cloud.ibm.com/docs/containers?topic=containers-encryptionverify_kms)
* [Managing encryption for the worker nodes in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption)



* [Classic worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption-classic)
* [VPC worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-encryptionworker-encryption-vpc)





[Configuring pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psppsp)



* [FAQs](https://cloud.ibm.com/docs/containers?topic=containers-psppsp-faqs)



* [Why do I set pod security policies?]
* [Experimental: ibmcloud ks nlb-dns secret rm](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_nlb-dns-secret-rm)



* [webhook-create command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_webhook_create)



* [Example webhook-create command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliwebhook-create-example)



* [api-key commands](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cliapi_key-commands)



* [ibmcloud ks api-key info](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_info)
* [ibmcloud ks api-key reset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_api_key_reset)



* [credential commands](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicredential)



* [ibmcloud ks credential get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credential_get)
* [ibmcloud ks credential set classic](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_set)
* [ibmcloud ks credential unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_credentials_unset)
[Helm](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/helm.svg) [Helm](https://helm.sh/) is a Kubernetes package manager that uses Helm charts to define, install, and upgrade complex Kubernetes apps in an IBM Cloud Kubernetes Service cluster. ![Check mark](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/checkmark.svg) 
 ![Operators](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/operator.png) [OpenShift Operators](https://www.redhat.com/en/technologies/cloud-computing/openshift/what-are-openshift-operators) are a convenient way to add and run community, Third party, and other services in a Red Hat OpenShift on IBM Cloud cluster. ![Check mark](https://cloud.ibm.com/docs-content/v1/content/ba89e173287b28d1453d2a327d8a1f74ae2f1662/schematics/images/checkmark.svg) 
 !
* UI
* API
* Terraform







 Working with Tekton pipelines 

[Tekton Pipelines](https://tekton.dev/) is an open source project that you can use to configure and run Continuous Integration and Continuous Delivery pipelines within a Kubernetes cluster. Tekton pipelines are defined in yaml files, which are typically stored in a Git repository (repo).

Zoom

![Hybrid Tekton Pipelines](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/Hybrid_tekton_workers.svg)

Figure 1. Hybrid Tekton pipelines diagram

Tekton provides a set of [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) extensions to Kubernetes to define pipelines. The following basic Tekton Pipeline resources are included in these extensions:



Table 1. Tekton pipeline resources

 Resource Description 

 Task Defines a set of build steps such as compiling code, running tests, and building and deploying images. 
 TaskRun Instantiates a Task for execution with specific inputs, outputs, and execution parameters. You can start the task on its own or as part of a pipeline. 
 Pipeline Defines the set of tasks that compose a pipeline. 
 PipelineRun Instantiates a Pipeline for execution with specific inputs, outputs, and execution parameters. 



You can take advantage of the following features when you use Tekton Pipelines:



* Cloud Native: Tekton Pipelines run on Kubernetes, use Kubernetes clusters as a first class type, and use containers as their building blocks.
* Decoupled: You can use one pipeline to deploy to any Kubernetes cluster. You can run the tasks that comprise a pipeline in isolation. And you can switch resources (such as Git repos) between pipeline runs.
kind: Service
metadata:
...
* You can use the kubectl apply -f command to apply to an entire directory, not just a single file.
* Try out the [kustomize project](https://cloud.ibm.com/docs/containers?topic=containers-appkustomize) that you can use to help write, customize, and reuse your Kubernetes resource YAML configurations.



Within the YAML file, you can use labels or annotations as metadata to manage your deployments.

Labels
: [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) are key:value pairs that can be attached to Kubernetes objects such as pods and deployments. They can be whatever you want, and are useful for selecting objects based on the label information. Labels provide the foundation for grouping objects. See the following examples for ideas for labels.



* app: nginx
* version: v1
* env: dev



Annotations
: [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) are similar to labels in that they are also key:value pairs. They are better for non-identifying information that can be leveraged by tools or libraries, such as holding extra information about where an object came from, how to use the object, pointers to related tracking repos, or a policy about the object. You don't select objects based on annotations.





 What app update strategies can I use? 

To update your app, you can choose from various strategies such as the following. You might start with a rolling deployment or instantaneous switch before you progress to a more complicated canary deployment.

Rolling deployment
: You can use Kubernetes-native functionality to create a v2 deployment and to gradually replace your previous v1 deployment. This approach requires that apps are compatible with earlier version so that users who are served the v2 app version don't experience any breaking changes.
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. In a replica set, you define how many instances of your app that you want to deploy. Replica sets are managed and monitored by your Kubernetes deployment. If one app instance goes down, Kubernetes automatically spins up a new instance of your app to maintain the specified number of app instances.

spec:
replicas: 3





 Labels 

With [labels](https://cloud.ibm.com/docs/containers?topic=containers-plan_deploydeploy_organize), you can mark different types of resources in your cluster with the same key: value pair. Then, you can specify the selector to match the label so that you can build upon these other resources. If you plan to expose your app publicly, you must use a label that matches the selector that you specify in the service. In the example, the deployment spec uses the template that matches the label app: wasliberty.

You can retrieve objects that are labeled in your cluster, such as to see staging or production components. For example, list all resources with an env: production label across all namespaces in the cluster. Note: You need access to all namespaces to run this command.

kubectl get all -l env=production --all-namespaces



* For more information about labels, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
kube-proxy uses Iptables rules, a Linux kernel feature, to direct requests to the pod behind a service equally, independent of pods' in-cluster IP addresses and the worker node that they are deployed to.

For example, apps inside the cluster can access a pod behind a cluster service by using the service's in-cluster IP or by sending a request to the name of the service. When you use the name of the service, kube-proxy looks up the name in the cluster DNS provider and routes the request to the in-cluster IP address of the service.

If you use a service that provides both an internal cluster IP address and an external IP address, clients outside of the cluster can send requests to the service's external public or private IP address. kube-proxy forwards the requests to the service's in-cluster IP address and load balances between the app pods behind the service.





 Understanding Kubernetes service types 

Kubernetes supports four basic types of network services: ClusterIP, NodePort, LoadBalancer, and Ingress. ClusterIP services make your apps accessible internally to allow communication between pods in your cluster only. NodePort, LoadBalancer, and Ingress services make your apps externally accessible from the public internet or a private network.

The following table compares the features of each network service type.



Characteristics of Kubernetes network service types

 Characteristics ClusterIP NodePort LoadBalancer (Classic - NLB) LoadBalancer (VPC load balancer) Ingress 

 Standard clusters Yes Yes Yes Yes Yes 
 Externally accessible Yes Yes Yes Yes 
 External hostname Yes Yes Yes 
 Stable external IP Yes Yes 
 HTTP(S) load balancing Yes* Yes* Yes 
 TLS termination Yes 
 Custom routing rules Yes 
 Multiple apps per service Yes 



* An SSL certificate for HTTPS load balancing is provided by ibmcloud ks nlb-dns commands. In classic clusters, these commands are supported for public NLBs only.



 ClusterIP 

You can expose apps only as [ClusterIP services](https://kubernetes.io/docs/concepts/services-networking/service/defining-a-service) on the private network.
* [Service](https://kubernetes.io/docs/concepts/services-networking/service/): Provides front-end access to pods by using a worker node or load balancer public IP address, or a public Ingress route.
* [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/): Specifies a type of load balancer that provides routes to access your app publicly.



Learn more about [securing your personal information](https://cloud.ibm.com/docs/containers?topic=containers-securitypi) when you work with Kubernetes resources.
2. Run the configuration file in a cluster's context.

kubectl apply -f config.yaml
3. If you made your app publicly available by using a NodePort service, a load balancer service, or Ingress, verify that you can access the app.







 Deploying apps to specific worker nodes by using labels 

When you deploy an app, the app pods indiscriminately deploy to various worker nodes in your cluster. Sometimes, you might want to restrict the worker nodes that the app pods to deploy to. For example, you might want app pods to deploy to only worker nodes in a certain worker pool because those worker nodes are on bare metal machines. To designate the worker nodes that app pods must deploy to, add an affinity rule to your app deployment.

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 are assigned a [service access role](https://cloud.ibm.com/docs/containers?topic=containers-userschecking-perms) that grants the appropriate Kubernetes RBAC role so that you can work with Kubernetes resources in the Kubernetes namespace.
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 load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. The following diagram illustrates how a user accesses an app's service through the load balancer, even though your worker node is connected to only a private subnet.

Zoom

![VPC load balancing for a cluster.](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/includes/containers/includes/containers/images/vpc-alb-mz.svg)

Figure 1. VPC load balancing for a cluster



1. Create a Kubernetes LoadBalancer service in your cluster to publicly expose the hello world app.

kubectl expose deployment/hello-world-deployment --type=LoadBalancer --name=hw-lb-svc --port=8080 --target-port=8080

Example output

service "hw-lb-svc" exposed



Table 2. Information about the command options.

 Parameter Description 

 expose Expose a Kubernetes resource, such as a deployment, as a Kubernetes service so that users can access the resource by using the IP address of the service. 
 deployment/<hello-world-deployment> The resource type and the name of the resource to expose with this service. 
 --name=<hello-world-service> The name of the service. 
 --type=LoadBalancer The Kubernetes service type to create. In this lesson, you create a LoadBalancer service. 
 --port=<8080> The port on which the service listens for external network traffic. 
 --target-port=<8080> The port that your app listens on and to which the service directs incoming network traffic.
Component Previous Current Description 

 containerd N/A 1.1.2 containerd replaces Docker as the new container runtime for Kubernetes. See the [containerd release notes](https://github.com/containerd/containerd/releases/tag/v1.1.2). 
 Docker N/A N/A containerd replaces Docker as the new container runtime for Kubernetes, to enhance performance. 
 etcd v3.2.14 v3.2.18 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.2.18). 
 IBM Cloud Provider v1.10.5-118 v1.11.2-60 Updated to support Kubernetes 1.11 release. In addition, load balancer pods now use the new ibm-app-cluster-critical pod priority class. 
 IBM Cloud File Storage for Classic plug-in 334 338 Updated incubator version to 1.8. File storage is provisioned to the specific zone that you select. You can't update an existing (static) PV instance labels. 
 Kubernetes v1.10.5 v1.11.2 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.11.2). 
 Kubernetes configuration N/A N/A Updated the OpenID Connect configuration for the cluster's Kubernetes API server to support IBM Cloud Identity Access and Management (IAM) access groups. Added Priority to the --enable-admission-plugins option for the cluster's Kubernetes API server and configured the cluster to support pod priority. For more information, see:<br><br><br><br> * [IBM Cloud IAM access groups](https://cloud.ibm.com/docs/containers?topic=containers-usersrbac)<br> * [Configuring pod priority](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritypod_priority)<br><br><br>
Component Previous Current Description 

 Kubernetes v1.9.7 v1.9.8 See th [Kubernetes release notes]([https://github.com/kubernetes/kubernetes/releases/tag/v1.9.8](https://github.com/kubernetes/kubernetes/releases/tag/v1.9.8)] 
 Kubernetes Configuration N/A N/A Added PodSecurityPolicy to the --admission-control option for the cluster's Kubernetes API server and configured the cluster to support pod security policies. For more information, see (/docs/containers?topic=containers-psp) [Configuring pod security policies]. 
 IBM Cloud Provider v1.9.7-102 v1.9.8-141 Updated to support Kubernetes 1.9.8 release. 
 OpenVPN client N/A N/A Added livenessProbe to the OpenVPN client vpn deployment that runs in the kube-system namespace. 







 Change log for worker node fix pack 1.9.7_1513, released 11 June 2018 

The following table shows the changes that are in the worker node fix pack 1.9.7_1513.



Table 1. Changes since version 1.9.7_1512

 Component Previous Current Description 

 Kernel update 4.4.0-116 4.4.0-127 New worker node images with kernel update for [CVE-2018-3639](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639) 







 Change log for worker node fix pack 1.9.7_1512, released 18 May 2018 

The following table shows the changes that are in the worker node fix pack 1.9.7_1512.



Table 1. Changes since version 1.9.7_1511

 Component Previous Current Description 

 Kubelet N/A N/A Fix to address a bug that occurred if you used the block storage plug-in.
[Diagram of a modern container architecture](https://cloud.ibm.com/docs-content/v1/content/cbb80bf851fb762a838129cba09d5674f8bfffda/Registry/includes/solution-tutorials/includes/solution-tutorials/images/solution30/modern_architecture.png)

Diagram of a modern container architecture



1. The user sends a request to the public endpoint of the app. The public endpoint is represented by an Ingress application load balancer (ALB) that load balances incoming network traffic across app pods in the cluster. The ALB is a collection of rules that allow inbound network traffic to a publicly exposed app.
2. The ALB forwards the request to one of the available app pods in the cluster. App pods run on worker nodes that can be a virtual or physical machine.
3. App pods store data in persistent volumes. Persistent volumes can be used to share data between app instances or worker nodes.
4. App pods store data in an IBM Cloud database service. You can run your own database inside the Kubernetes cluster, but using a managed database-as-a-service (DBaaS) is usually easier to configure and provides built-in backups and scaling. You can find many different types of databases in the [IBM Cloud catalog](https://cloud.ibm.com/catalog?category=databasesservices).







 VMs, containers, and Kubernetes 

Kubernetes Service provides the capability to run containerized apps in Kubernetes clusters and delivers the following tools and functions:



* Intuitive user experience and powerful tools.
* Built-in security and isolation to enable rapid delivery of secure applications.
* Cloud services that include cognitive capabilities from IBM® Watson™.
* Ability to manage dedicated cluster resources for both stateless applications and stateful workloads.





 Virtual machines vs containers 

VMs, traditional apps run on native hardware. A single app does not typically use the full resources of a single compute host. Most organizations try to run multiple apps on a single compute host to avoid wasting resources.