vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: [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. For more information, see [Managing rolling deployments to update your apps](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appapp_rolling).

Instantaneous switch
: Also referred to as a blue-green deployment, an instantaneous switch requires double the compute resources to have two versions of an app running at once. With this approach, you can switch your users to the newer version in near real time. Make sure that you use service label selectors (such as version: green and version: blue) to make sure that requests are sent to the correct app version.
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-bronze"
labels:
billingType: "hourly"
app: wasliberty
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 24Gi
Show more





 Packaging apps for reuse in multiple environments with Kustomize 

As part of a [twelve-factor](https://12factor.net/), cloud-native app, you want to maintain dev-to-prod parity by setting up a continuous development and delivery pipeline that uses a common, version-controlled code base source. In your code base repositories, you store your Kubernetes resource configuration manifest files, often in YAML format. You can use the Kubernetes project [Kustomize](https://kustomize.io/) both to standardize and customize your deployments across multiple environments.

For example, you can set up a base kustomization YAML file to declare Kubernetes objects such as deployments and PVCs that are shared in your development, testing, and production environments. Next, you can set up separate kustomization YAML files that have customized configurations for each environment, such as more replicas in production than testing. These customized YAML files can then overlay, or build on, the shared base YAML file so that you can manage environments that are mostly identical except for a few overlay configuration differences that you source-control. For more information about Kustomize such as a glossary and FAQs, check out the [Kustomize docs](https://kubectl.docs.kubernetes.io/references/kustomize/).

Before you begin: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).

To set up configuration files with Kustomize:



1.
kubectl get statefulset --all-namespaces

Example output

NAME DESIRED CURRENT AGE
mystatefulset 3 3 6s
2. View the Pods Status of each stateful set to ensure that the deployment of the stateful set is finished.

kubectl describe statefulset <statefulset_name>

Example output

Name: nginx
Namespace: default
CreationTimestamp: Fri, 05 Oct 2022 13:22:41 -0400
Selector: app=nginx,billingType=hourly,region=us-south,zone=dal10
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
Replicas: 3 desired | 3 total
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10

A stateful set is fully deployed when the number of replicas that you find in the Replicas section of your CLI output equals the number of Running pods in the Pods Status section. If a stateful set is not fully deployed yet, wait until the deployment is finished before you proceed.
3. Create a configuration file for your stateful set and the service that you use to expose the stateful set.

Example stateful set that specifies a zone. The following example shows how to deploy NGINX as a stateful set with 3 replicas. For each replica, a 20 gigabyte File Storage for Classic device is provisioned based on the specifications in the ibmc-file-retain-bronze storage class. All storage devices are provisioned in the dal10 zone.
* [ibmcloud ks cluster image-security disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics-image-security-disable)
* [ibmcloud ks cluster image-security enable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics-image-security-enable)
* [ibmcloud ks cluster ls](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_clusters)
* [ibmcloud ks cluster master audit-webhook](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster_master_audit_webhook)
* [ibmcloud ks cluster master pod-security get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-get)
* [ibmcloud ks cluster master pod-security policy disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-disable)
* [ibmcloud ks cluster master pod-security policy enable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-enable)
* [ibmcloud ks cluster master pod-security policy get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-policy-get)
* [ibmcloud ks cluster master pod-security set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-set)
How can I resolve the network error when working with the Kubernetes Service provider? 

  What’s happening 

During the cluster upgrade from Kubernetes Service older version to new version. The Terraform apply fails with the TCP connection error message.

Error: Get "http://localhost/api/v1/": dial tcp [::1]:80: connect: connection refused

Or

Error: {{site.data.keyword.containershort_notm}} cluster unreachable: invalid configuration: no configuration has been provided

  Why it’s happening 

You are combining the cluster provisioning and working with the Kubernetes Service provider at the same time in your Terraform template in the IBM Cloud Schematics workspace or in your localhost. You make a change in the cluster configuration that leads to the cluster re-create. When you run terraform refresh command, you view strange errors such as, network or namespace issues.

  How to fix it 

To troubleshoot this error you need to ensure:



*  You don't combine the Kubernetes Service provider with the cluster resource at the same time in the Terraform template.
*  The resources should not be created in the same Terraform template or module where Kubernetes Service provider resources are in use.
*  The Terraform provider evaluates the provider blocks versus actual resource, and the order in which the resources are defined. For more information, see [Provider configuration](https://developer.hashicorp.com/terraform/language/providers/configurationprovider-configuration).



If you cannot resolve this issue, contact support by opening a support case for the service that you want to work with. Make sure to include the incident ID. For more information, see [Using the Support Center](https://cloud.ibm.com/docs/get-support?topic=get-support-using-avatar).
--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. In this example, the target-port is the same as the port, but other apps that you create might use a different port. 



2. Verify that the Kubernetes LoadBalancer service is created successfully in your cluster. When you create the Kubernetes LoadBalancer service, a VPC load balancer is automatically created for you. The VPC load balancer assigns a hostname to your Kubernetes LoadBalancer service that you can see in the LoadBalancer Ingress field of your CLI output. The VPC load balancer takes a few minutes to provision in your VPC. Until the VPC load balancer is ready, you can't access the Kubernetes LoadBalancer service through its hostname.

kubectl describe service hw-lb-svc

Example CLI output

NAME: hw-lb-svc
Namespace: default
Labels: app=hello-world-deployment
Annotations: <none>
Selector: app=hello-world-deployment
Type: LoadBalancer
IP: 172.21.xxx.xxx
LoadBalancer Ingress: 1234abcd-us-south.lb.appdomain.cloud
Port: <unset> 8080/TCP
TargetPort: 8080/TCP
NodePort: <unset> 32040/TCP
Endpoints:
Session Affinity: None
External Traffic Policy: Cluster
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal EnsuringLoadBalancer 1m service-controller Ensuring load balancer
kubectl get statefulset --all-namespaces

Example output

NAME DESIRED CURRENT AGE
mystatefulset 3 3 6s
2. View the Pods Status of each stateful set to ensure that the deployment of the stateful set is finished.

kubectl describe statefulset <statefulset_name>

Example output

Name: nginx
Namespace: default
CreationTimestamp: Fri, 05 Oct 2022 13:22:41 -0400
Selector: app=nginx,billingType=hourly,region=us-south,zone=dal10
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
Replicas: 3 desired | 3 total
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
billingType=hourly
region=us-south
zone=dal10
...

A stateful set is fully deployed when the number of replicas that you find in the Replicas section of your CLI output equals the number of Running pods in the Pods Status section. If a stateful set is not fully deployed yet, wait until the deployment is finished before you proceed.
3. Create a configuration file for your stateful set and the service that you use to expose the stateful set. The following example shows how to deploy NGINX as a stateful set with three replicas. For each replica, a 20 gigabyte block storage device is provisioned based on the specifications that are defined in the ibmc-block-retain-bronze storage class. All storage devices are provisioned in the dal10 zone.
For more information on how to interpret this view, see [About Clusters Overview](https://docs.sysdig.com/en/docs/sysdig-monitor/advisor/overview/clusters-data/).





 Monitoring Kubernetes clusters by node 

When you choose to monitor your Kubernetes clusters by node, you can choose any of the following dashboards:



* Node Status & Performance
* Pod Scheduling Troubleshooting
* Node Overview
* CPU Allocation Optimization
* Memory Allocation Optimization



For more information on how to interpret this view, see [About Nodes Overview](https://docs.sysdig.com/en/docs/sysdig-monitor/advisor/overview/nodes-data/).





 Monitoring Kubernetes clusters by namespace 

When you choose to monitor your Kubernetes clusters by namespace, you can select more filters to display data by workload, or you can choose any of the following dashboards:



* Workload Status & Performance
* Pod Status & Performance
* Pod Rightsizing & Workload Capacity Optimization
* Namespace Overview
* Workloads CPU Usage and Allocation
* Workloads Memory Usage and Allocation



For more information on how to interpret this view, see [About Namespaces Overview](https://docs.sysdig.com/en/docs/sysdig-monitor/advisor/overview/namespaces-data/).





 Monitoring Kubernetes clusters by workloads 

When you choose to monitor your Kubernetes clusters by workloads, you can choose any of the following dashboards:



* Container Resource Usage & Troubleshooting
* Pod Status & Performance
* Pod Rightsizing & Workload Capacity Optimization
* Workload Status & Performance
* Deployment Overview
* Pod Overview
* Workloads CPU Usage and Allocation
* Workloads Memory Usage and Allocation



For more information on how to interpret this view, see [About Workloads Overview](https://docs.sysdig.com/en/docs/sysdig-monitor/advisor/overview/workloads-data/).





 Monitoring hosts
The resource files in the source repository is automatically deployed to the clusters that belong to the selected cluster group.







 Understanding Direct Upload configurations 

Store your Kubernetes resource definitions in Satellite Config by either manually uploading your YAML files or pushing YAML files from your CI/CD process. Manage changes directly through Satellite Config GUI, CLI, or from your CI/CD process. To use this method, select the Direct upload template when you create your configuration.

Zoom

![How Satellite configurations work](https://cloud.ibm.com/docs-content/v1/content/c8335d66af691d19e837116fd633481c477061eb/satellite//images/satcon-direct-upload.svg)

Figure 2. How Direct upload configurations work

A Direct Upload configuration involves the follow high-level steps.



1. Create a Satellite configuration and create versions by uploading Kubernetes resource files. Each Kubernetes resource file that you upload represents a version within the configuration.
2. Create a subscription to associate a version with one or more cluster groups.
3. The version of the Kubernetes resource file that is specified in the subscription is automatically deployed to the clusters that belong to the selected cluster group.







 Key concepts for Satellite Config 

Review the following key concepts that are used when you create a Satellite configuration.



Satellite config key concepts.

 Term Description 

 Configuration With Satellite configuration, you can upload or create Kubernetes resource YAML file versions to deploy to a group of clusters. The version that you upload is not applied to your cluster until you add a subscription to your configuration. 
 Subscription A Satellite subscription specifies which Kubernetes resource is deployed to one or more cluster groups. After you create the subscription, Satellite Config automatically downloads the Kubernetes resource that you specified and starts applying it across all clusters that belong to the cluster group. This process takes a few minutes to complete. <br>The clusters in your cluster group can exist in your Satellite or in IBM Cloud.
Kubernetes version 1.16
* Deprecated: Kubernetes version 1.13
* Unsupported: Kubernetes version 1.12



* [1 November 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-nov0119)



* New! Keep your own key (KYOK) support (beta)





* [October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct19)



* [28 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct2819)



* Version change logs
* New! Resource groups for VPC clusters



* [24 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct2419)



* CLI change log
* Scaling down file storage
* Ingress subdomain troubleshooting



* [23 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct2319)



* Ingress ALB change log
* Ingress annotations



* [22 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct2219)



* Version change logs



* [17 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct1719)



* New! Cluster autoscaler
* New DevOps tutorial



* [14 October 2019](https://cloud.ibm.com/docs/containers?topic=containers-containers-relnotescontainers-oct1419)



* CLI change log
* Calico MTU
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.
* Typed: You can switch implementations for specific types of resources, such as images.



The Tekton Pipelines project is a beta release. You must update your pipeline with each new version of Tekton. For more information about the latest version of Tekton, see [https://github.com/tektoncd/pipeline/releases](https://github.com/tektoncd/pipeline/releases).

IBM Cloud® Continuous Delivery provides two types of delivery pipelines that you can use to build, test, and deploy your applications.



* Classic: Classic delivery pipelines are created graphically, with the status embedded in the pipeline diagram. These pipelines can run on shared workers in the cloud or on private workers that run on your own Kubernetes cluster.
* Tekton: Tekton delivery pipelines are created within yaml files that define pipelines as a set of Kubernetes resources. You can edit those yaml files to change the behavior of a pipeline. Tekton pipelines can run on private workers that run on your own cluster. They can also run on IBM-managed workers on the public cloud. The Tekton integration provides a dashboard that you can use to view the output of Tekton pipeline runs. It also provides mechanisms for identifying the pipeline definitions repo, the pipeline triggers, where the pipeline runs, and the storage and retrieval of properties.



Both types of pipelines isolate jobs or steps from one another by running in separate containers, and by using an image that you choose.
Docker N/A N/A For non-encrypted flavors, the secondary disk is cleaned by getting a fresh file system when you reload or update the worker node. 







 Change log for 1.10.3_1512, released 12 June 2018 

The following table shows the changes that are in patch 1.10.3_1512.



Table 1. Changes since version 1.10.1_1510

 Component Previous Current Description 

 Kubernetes v1.10.1 v1.10.3 See the Kubernetes [release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.10.3). 
 Kubernetes Configuration N/A N/A Added PodSecurityPolicy to the --enable-admission-plugins option for the cluster's Kubernetes API server and configured the cluster to support pod security policies. For more information, see [Configuring pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp). 
 Kubelet Configuration N/A N/A Enabled the --authentication-token-webhook option to support API bearer and service account tokens for authenticating to the kubelet HTTPS endpoint. 
 IBM Cloud Provider v1.10.1-52 v1.10.3-85 Updated to support Kubernetes 1.10.3 release. 
 OpenVPN client N/A N/A Added livenessProbe to the OpenVPN client vpn deployment that runs in the kube-system namespace. 
 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.10.1_1510, released 18 May 2018 

The following table shows the changes that are in the worker node fix pack 1.10.1_1510.



Table 1. Changes since version 1.10.1_1509
This section is an array of descriptors and supports two types of descriptors: [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) and [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/).

The following example illustrates how to use the resources section:

workload:
type: workload
play:
resources:
- apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
containers:
- name: main
image: ...
command:
- printenv
envFrom:
- configMapRef:
name: contract.config.map
optional: false
restartPolicy: Never
Show more
* In the archive subsection of play. The archive is a base64 encoded, gzipped tar file. The Pods or ConfigMaps are represented as YAML files, top level in this tar file. The file may also contain extra files and all files will be extracted to the host file system before starting the Pods. The current working directory is the directory in which the files have been extracted, so it's possible to use a volume mount with a relative path to mount files or directories from the contract.
* In a template format in the templates subsection of play. This section is an array of descriptors in the YAML format. [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) or [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) may have points of variability (POV) that are not known at the time of writing the descriptors. These POVs may be represented as [templates](https://pkg.go.dev/text/template) and the values will be filled in at deployment time from information in the contract.
The application source code can be found in this [GitHub repository](https://github.com/IBM-Cloud/kubernetes-node-app/).

kubectl create deploy hello-world-deployment --image=icr.io/solution-tutorials/tutorial-scalable-webapp-kubernetes

Example output: deployment "hello-world-deployment" created.
3. Make the application accessible within the cluster by creating a service:

kubectl expose deployment/hello-world-deployment --type=ClusterIP --port=80 --name=hello-world-service --target-port=3000

It returns message like service "hello-world-service" exposed. To see the services:

kubectl get services
4. Run the application in the cluster with two replicas:

kubectl scale deployment hello-world-deployment --replicas=2
5. You can check the status of the deployment with the following command:

kubectl get pods







 Get the Ingress Subdomain assigned to the cluster 

When a Kubernetes cluster is created, it gets assigned an Ingress subdomain (for example, my-us-cluster.us-south.containers.appdomain.cloud) and a public Application Load Balancer IP address.



1. Retrieve the Ingress subdomain of the cluster:

ibmcloud ks cluster get --cluster $MYCLUSTER

Look for the Ingress Subdomain value.
2. Make note of this information for a later step.



This tutorial uses the Ingress Subdomain to configure the Global Load Balancer. You could also replace the Ingress Subdomain with the public Application Load Balancer, ALB of the cluster. An <IngressSubdomain> looks something like my-us-cluster-e7f2ca73139645ddf61a8702003a483a-0000.us-south.containers.appdomain.cloud





 Configure the Ingress for your DNS subdomain