vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Why does my app fail when a non-root user owns the NFS file storage mount path? 

Classic infrastructure

 What’s happening 

After you [add NFS storage](https://cloud.ibm.com/docs/openshift?topic=openshift-file_storagefile_app_volume_mount) to your deployment, the deployment of your container fails. When you retrieve the logs for your container, you might see errors such as the following. The pod fails and is stuck in a reload cycle.

write-permission

don't have required permission

can't create directory '/bitnami/mariadb/data': Permission denied

 Why it’s happening 

By default, non-root users don't have write permission on the volume mount path for NFS-backed storage. Some common app images, such as Jenkins and Nexus3, specify a non-root user that owns the mount path in the Dockerfile.

When you create a container from this Dockerfile, the creation of the container fails due to insufficient permissions of the non-root user on the mount path. To grant write permission, you can modify the Dockerfile to temporarily add the non-root user to the root user group before it changes the mount path permissions, or use an init container.

If you use a Helm chart to deploy the image, edit the Helm deployment to use an init container.

 How to fix it 

When you include an [init container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) in your deployment, you can give a non-root user that is specified in your Dockerfile write permissions for the volume mount path inside the container.

The init container starts before your app container starts. The init container creates the volume mount path inside the container, changes the mount path to be owned by the correct (non-root) user, and closes. Then, your app container starts with the non-root user that must write to the mount path. Because the path is already owned by the non-root user, writing to the mount path is successful.
include = ["${TF_NETWORK_MIRROR_PROVIDER_NAME}"]
}
direct {
exclude = ["TF_NETWORK_MIRROR_PROVIDER_NAME"]
}
}
* How do I set the credentials to access a private provider registry

When interacting with private registries, Terraform must be configured with the access tokens for the target registry. With Agents these are defined at a workspace level using the TF_TOKEN_ environment variable. See the Terraform [Environment Variable Credentials](https://developer.hashicorp.com/terraform/cli/config/config-fileenvironment-variable-credentials) documentation for more detail on configuring this variable.
* Using Artifactory as a provider registry

[Artifactory](https://jfrog.com/artifactory/) provides a number of different options for sourcing of Terraform providers and fully supports the [Terraform provider registry protocol](https://developer.hashicorp.com/terraform/internals/provider-registry-protocol). It supports, remote, local and virtual repositories which aggregate the first two types with a defined search order.

Local repositories are physical, user managed local repositories acting as a Terraform private registry where you can host custom developed providers and manually upload and save public providers to eliminate the need for public network access. Or limit the public providers made available to Terraform users.

Remote repositories can serve as a caching proxy for both private Terraform registries and the public Terraform registry. Implementing a remote repository still requires public internet access. Here public network access is via Artifactory and not Terraform. Typically many organizations have existing Artifactory installations, with network monitoring and network access rules in place to allow secure public access from Artifactory.

A virtual Terraform repository, combining a local repo with a remote proxy repo, allows for hosting of custom providers locally along with secure access to any additional public Terraform providers.



 Configuring a local Artifactory provider registry 

A local Artifactory registry can be used to host custom developed providers for use with agents in a users private network.
Check your secrets. In a build, secrets are used for the following purposes:



* To authenticate at the container registry. A registry secret stores credentials to access a container registry. To list all secrets in your project, including existing registry secrets, run the [ibmcloud ce secret list](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-list) command. To create a registry secret, run the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. For more information about registry secrets, see [Adding access to a private container registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).
* To authenticate at a private source code repository. An SSH secret stores credentials to authenticate to a service with an SSH key, such as authenticating to a Git repository, such as GitHub or GitLab. To list all secrets in your project, including existing SSH secrets, run the [ibmcloud ce secret list](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-list) command. To create an SSH secret, run the [ibmcloud ce secret create --format ssh](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command. For more information about SSH secrets to access repositories, see [Accessing private code repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories).



2. After secrets are defined, use the [ibmcloud ce build update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-update) command to update the build configuration.
To get the most out of your worker node's performance, consider the following: - Keep up your core strength: Each machine has a certain number of cores. Depending on your app's workload, set a limit for the number of pods per core, such as 10. - Avoid node overload: Similarly, just because a node can contain more than 100 pods doesn't mean that you want it to. Depending on your app's workload, set a limit for the number of pods per node, such as 40. - Don't tap out your cluster bandwidth**: Keep in mind that network bandwidth on scaling virtual machines is around 1000 Mbps. If you need hundreds of worker nodes in a cluster, split it up into multiple clusters with fewer nodes, or order bare metal nodes. - Sorting out your services: Plan out how many services that you need for your workload before you deploy. Networking and port forwarding rules are put into Iptables. If you anticipate a larger number of services, such as more than 5,000 services, split up the cluster into multiple clusters.





 Provision different types of machines for a mix of computing resources 

Everyone likes choices, right? With IBM Cloud Kubernetes Service, you have [a mix of flavors](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesplanning_worker_nodes) that you can deploy: from bare metal for intensive workloads to virtual machines for rapid scaling. Use labels or namespaces to organize deployments to your machines. When you create a deployment, limit it so that your app's pod deploys only on machines with the best mix of resources. For example, you might want to limit a database application to a bare metal machine with a significant amount of local disk storage like the md1c.28x512.4x4tb.





 Set up multiple namespaces when you have multiple teams and projects that share the cluster 

Namespaces are kind of like a cluster within the cluster.
Allowing SSH and pinging to a public subnet 

In this guide, learn how to configure the IBM Cloud® Juniper vSRX Standard with a new interface, zone, and address-book. As the default action for all traffic is to drop, this guide shows how to set up traffic flows that allow all traffic within the new zone, all traffic from the new zone to the internet, and allow only SSH and ping from the internet to one subnet on the new VLAN.

In this example, the following values are used.



*  Public vlan: 1523
*  Public subnet: 169.47.211.152/29



This step-by-step assumes that a high-availability deployment of the vSRX, with a single Public VLAN and subnet.



  What you'll accomplish 

In this step-by-step guide learn how to configure the service:



 Task                                                                                                              Description                                                                      

 [Create a new interface, zone, and address-book subnet](https://cloud.ibm.com/docs/vsrx?topic=vsrx-creating-the-new-interface-zone-and-address-book-subnet)   Create the tagged interface unit and security zone for the new VLAN.             
 [Creating your new traffic flows](https://cloud.ibm.com/docs/vsrx?topic=vsrx-creating-your-new-traffic-flows)                                                                               Create the new traffic flows to allow inbound pinging and SSH.                   
 [Confirm the output and commit the changes](https://cloud.ibm.com/docs/vsrx?topic=vsrx-confirming-the-output-and-commiting-the-changes)                                                                     Check the output to confirm what will be committed to the active configuration.
4. Review the list of images. To run the policy and delete the images, confirm that you want to set the policy.

If you don't want to delete those images, choose No. The policy is not set and the images are not deleted.
5. Verify that the images were deleted by running the following command, and check that the images show in the list.

ibmcloud cr trash-list
6. Verify that the policy is set by running the [ibmcloud cr retention-policy-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_policy_list) command, and check that the policy that you set for the namespace retains the required number of images. If you set the policy to retain all untagged images, ensure that the Retain all untagged column has the value true.

ibmcloud cr retention-policy-list







 Update a retention policy to keep all your images 

All namespaces have a default policy that keeps all images. You can return a policy to the default state.

You can use the [ibmcloud cr retention-policy-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_retention_policy_set) command to set the policy back to the default state by running the following command, where <namespace> is your namespace:

ibmcloud cr retention-policy-set --images All <namespace>





 Clean up your namespaces by deleting untagged images 

You can clean up your namespace and reduce your bills by deleting your [untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewoverview_elements_untagged) images in the namespace and optionally output the results in JSON format.
To follow a tutorial that demonstrates how to set up service accounts for Travis and Jenkins and to assign custom RBAC roles to the service accounts, see the blog post [Kubernetes ServiceAccounts for use in automated systems](https://medium.com/@jakekitchener/kubernetes-serviceaccounts-for-use-in-automated-systems-515297974982).

To prevent breaking changes, don't change the predefined view, edit, admin, and cluster-admin cluster roles. Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with IBM Cloud IAM service access roles.



* Namespace access: To allow a user, access group, or service account to access a resource within a specific namespace, choose one of the following combinations:



* Create a role, and apply it with a role binding. This option is useful for controlling access to a unique resource that exists only in one namespace, like an app deployment.
* Create a cluster role, and apply it with a role binding. This option is useful for controlling access to general resources in one namespace, like pods.



* Cluster-wide access: To allow a user or an access group to access cluster-wide resources or resources in all namespaces, create a cluster role, and apply it with a cluster role binding. This option is useful for controlling access to resources that are not scoped to namespaces, like worker nodes, or resources in all namespaces in your cluster, like pods in each namespace.
* [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)
* Ensure you that have the [Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users) for all namespaces.
* Verify that you are assigned the Administrator platform access role and the Manager service access role for all Kubernetes namespaces in IBM Cloud Kubernetes Service to create the logging configuration. To view a logging configuration or launch the Log Analysis dashboard after the logging configuration is created, users must be assigned the Viewer platform access role and Reader service access role for the ibm-observe Kubernetes namespace in IBM Cloud Kubernetes Service.
* If you want to use the CLI to set up the logging configuration:



* [Install the IBM Cloud Kubernetes Service observability CLI plug-in (ibmcloud ob)](https://cloud.ibm.com/docs/containers?topic=containers-cli-install).
* [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)





To set up a logging configuration for your cluster,



1. Create an [IBM Log Analysis service instance](https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-provision) and note the name of the instance. The service instance must belong to the same IBM Cloud account where you created your cluster, but can be in a different resource group and IBM Cloud region than your cluster.
2. Set up a logging configuration for your cluster. When you create the logging configuration, a Kubernetes namespace ibm-observe is created and a Log Analysis agent is deployed as a daemon set to all worker nodes in your cluster. This agent collects logs with the extension .log and extensionless files that are stored in the /var/log directory of your pod from all namespaces, including kube-system. The agent then forwards the logs to the IBM Log Analysis service.



* From the console



1. From the [Kubernetes clusters console](https://cloud.ibm.com/kubernetes/clusters), select the cluster for which you want to create a Log Analysis configuration.
2. On the cluster Overview page, click Connect.
3.
: Curated learning paths for [administrators](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-admin) and [developers](https://cloud.ibm.com/docs/containers?topic=containers-learning-path-dev) are now available to help guide you through your IBM Cloud Kubernetes Service experience.

Setting up image build pipelines
: You can now find expanded information on how to set up an image registry and build pipelines in the following pages.



* [Setting up an image registry](https://cloud.ibm.com/docs/containers?topic=containers-registry)
* [Setting up continuous integration and delivery](https://cloud.ibm.com/docs/containers?topic=containers-cicd)



Firewall subnets
: Removed outdated [subnet IP addresses for IBM Cloud Container Registry](https://cloud.ibm.com/docs/containers?topic=containers-firewallvyatta_firewall).





 17 February 2020 

Kubernetes version 1.17
: [Kubernetes 1.17 release is certified](https://cloud.ibm.com/docs/containers?topic=containers-cs_versionsk8s_version_archive).

Version change logs
: Master and worker node patch updates.
Even if you over or underestimate, you can easily scale up or down your cluster, by changing either the number or size of worker nodes.

To run a production app in the cloud by using Kubernetes, consider the following items:



1. Do you expect traffic from a specific geographic location? If yes, select the location that is physically closest to you for best performance.
2. How many replicas of your cluster do you want for higher availability? A good starting point might be three clusters, one for development, one for testing and one for production. Check out the [Best practices for organizing users, teams, applications](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-users-teams-applicationsusers-teams-applications-5) solution guide for creating multiple environments.
3. What [hardware](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes) do you need for the worker nodes? Virtual machines or bare metal?
4. How many worker nodes do you need? This depends highly on the apps scale, the more nodes you have the more resilient your app will be.
5. How many replicas should you have for higher availability? Deploy replica clusters in multiple locations to make your app more available and protect the app from being down due to a location failure.
6. Which is the minimal set of resources your app needs to startup? You might want to test your app for the amount of memory and CPU it requires to run. Your worker node should then have enough resources to deploy and start the app. Make sure to then set resource quotas as part of the pod specifications. This setting is what Kubernetes uses to select (or schedule) a worker node that has enough capacity to support the request. Estimate how many pods will run on the worker node and the resource requirements for those pods. At a minimum, your worker node must be large enough to support one pod for the app.
7. When to increase the number of worker nodes? You can monitor the cluster usage and increase nodes when needed.
You can create simple [Kubernetes network policies](https://cloud.ibm.com/docs/containers?topic=containers-vpc-kube-policies) to isolate app microservices from each other within a namespace or across namespaces.

By default, any pod has access to any other pod in the cluster. Additionally, any pod has access to any services that are exposed by the pod network, such as a metrics service, the cluster DNS, the API server, or any services that you manually create in your cluster.





 Logging denied traffic 

To log denied traffic requests to certain pods in your cluster, you can create a Calico log network policy.

When you set up network policies to limit traffic to app pods, traffic requests that are not permitted by these policies are denied and dropped. In some scenarios, you might want more information about denied traffic requests. For example, you might notice some unusual traffic that is continuously being denied by one of your network policies. To monitor the potential security threat, you can set up logging to record every time that the policy denies an attempted action on specified app pods.

This section shows you how to log traffic that is denied by a Kubernetes network policy. To log traffic that is denied by a Calico network policy, see [Lesson 5 of the Calico network policy tutorial](https://cloud.ibm.com/docs/containers?topic=containers-policy_tutoriallesson5).

Before you begin, [install and configure the Calico CLI, and set the context for your cluster to run Calico commands](https://cloud.ibm.com/docs/containers?topic=containers-network_policiescli_install).



1. Create or use an existing Kubernetes network policy that blocks or limits incoming traffic.



1. Create a Kubernetes network policy. For example, to control traffic between pods, you might use the following example Kubernetes policy that is named access-nginx that limits access to an NGINX app. Incoming traffic to pods that are labeled "run=nginx" is allowed only from pods with the "run=access" label.
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/bcd8b79ca2ed73bfcaefb20051f12cb6400286ab/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/bcd8b79ca2ed73bfcaefb20051f12cb6400286ab/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/bcd8b79ca2ed73bfcaefb20051f12cb6400286ab/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/bcd8b79ca2ed73bfcaefb20051f12cb6400286ab/icons/checkmark-icon.svg) 



[V2] is only applicable once you have [migrated to the V2 configuration.](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-migration)[V1] is only applicable to the V1 configuration and is unavailable after you migrate to the V2 configuration. All others are applicable to both configurations.





 How do I know which access policies are set for me? 

You can see which access policies are set for you in the [IBM Cloud UI](https://cloud.ibm.com/) console.



1. Go to [Access IAM users](https://cloud.ibm.com/iam/users).
2. Click your name in the user table.
3. Click the Access policies tab to see your access policies.
4. Click the Access groups tab to see the access groups where you are a member. Check the policies for each group.
To see the destination rules that are applied to BookInfo, run the following command.

kubectl describe destinationrules







 Including apps in the Istio service mesh by setting up sidecar injection 

Ready to manage your own apps by using Istio? Before you deploy your app, you must first decide how you want to inject the Envoy proxy sidecars into app pods.

Each app pod must be running an Envoy proxy sidecar so that the microservices are in the service mesh. You can make sure that sidecars are injected into each app pod automatically or manually. For more information about sidecar injection, see the [Istio documentation](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/).



 Enabling automatic sidecar injection 

When automatic sidecar injection is enabled, a namespace listens for any new deployments and automatically modifies the pod template specification so that app pods are created with Envoy proxy sidecar containers. Enable automatic sidecar injection for a namespace when you plan to deploy multiple apps that you want to integrate with Istio into that namespace. Automatic sidecar injection is not enabled for any namespaces by default in the Istio managed add-on.

Do not enable sidecar injection for the kube-system, ibm-system, or ibm-operators namespaces.

To enable automatic sidecar injection for a namespace:



1. Get the name of the namespace where you want to deploy Istio-managed apps.

kubectl get namespaces
2. Label the namespace as istio-injection=enabled.

kubectl label namespace <namespace> istio-injection=enabled
3. Deploy apps into the labeled namespace, or redeploy apps that are already in the namespace.

kubectl apply <myapp>.yaml --namespace <namespace>
4. Optional To redeploy an app in that namespace, delete the app pod so that it is redeployed with the injected sidecar.

kubectl delete pod -l app=<myapp>
5.