Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

29 Managing Nproc Limits of Pods

Warning
Warning: Do Not Adjust Without Guidance

It is not recommended to change these values without the guidance of SUSE Cloud Application Platform developers. Please contact support for assistance.

Nproc is the maximum number of processes allowed per user. In the case of scf, the nproc value applies to the vcap user. In scf, there are parameters, kube.limits.nproc.soft and kube.limits.nproc.hard, to configure a soft nproc limit and a hard nproc limit for processes spawned by the vcap user in scf pods. By default, the soft limit is 1024 while the hard limit is 2048. The soft and hard limits can be changed to suit your workloads. Note that the limits are applied to all pods.

When configuring the nproc limits, take note that:

  • If the soft limit is set, the hard limit must be set as well.

  • If the hard limit is set, the soft limit must be set as well.

  • The soft limit cannot be greater than the hard limit.

29.1 Configuring and Applying Nproc Limits

To configure the nproc limits, add the following to your scf-config-values.yaml. Replace the example values with limits suitable for your workloads:

kube:
  limits:
    nproc:
      hard: 3072
      soft: 2048

29.1.1 New Deployments

Note
Note: Embedded uaa in scf

The User Account and Authentication (uaa) Server is included as an optional feature of the scf Helm chart. This simplifies the Cloud Application Platform deployment process as a separate installation and/or upgrade of uaa is no longer a prerequisite to installing and/or upgrading scf.

It is important to note that:

  • This feature should only be used when uaa is not shared with other projects.

  • You cannot migrate from an existing external uaa to an embedded one. In this situation, enabling this feature during an upgrade will result in a single admin account.

To enable this feature, add the following to your scf-config-values.yaml.

enable:
  uaa: true

When deploying and/or upgrading scf, run helm install and/or helm upgrade and note that:

  • Installing and/or upgrading uaa using helm install suse/uaa ... and/or helm upgrade is no longer required.

  • It is no longer necessary to set the UAA_CA_CERT parameter. Previously, this parameter was passed the CA_CERT variable, which was assigned the CA certificate of uaa.

For new SUSE Cloud Application Platform deployments, follow the steps below to deploy SUSE Cloud Application Platform with nproc limits configured:

  1. Deploy uaa:

    tux > helm install suse/uaa \
    --name susecf-uaa \
    --namespace uaa \
    --values scf-config-values.yaml

    Wait until you have a successful uaa deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace uaa'

    When uaa is successfully deployed, the following is observed:

    • For the secret-generation pod, the STATUS is Completed and the READY column is at 0/1.

    • All other pods have a Running STATUS and a READY value of n/n.

    Press CtrlC to exit the watch command.

  2. Deploy scf:

    Note
    Note: Setting UAA_CA_CERT

    Starting with SUSE Cloud Application Platform 1.5.2, you no longer need to set UAA_CA_CERT when using an external UAA with a certificate signed by a well known Certificate Authority (CA). It is only needed when you use an external UAA with either a certificate generated by the secret-generator or a self-signed certificate.

    If you need to set UAA_CA_CERT:

    1. Obtain your UAA secret and certificate:

      tux > SECRET=$(kubectl get pods --namespace uaa \
      --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
      
      tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
      --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
    2. Then pass --set "secrets.UAA_CA_CERT=${CA_CERT}" as part of your helm command.

    tux > helm install suse/cf \
    --name susecf-scf \
    --namespace scf \
    --values scf-config-values.yaml
  3. Monitor the deployment progress using the watch command:

    tux > watch --color 'kubectl get pods --namespace scf'
  4. Open a shell into any container. The command below opens a shell to the default container in the blobstore-0 pod:

    tux > kubectl exec --stdin --tty blobstore-0 --namespace scf -- env /bin/bash
  5. Use the vcap user identity:

    tux > su vcap
  6. Verify the maximum number of processes for the vcap user matches the limits you set:

    tux > ulimit -u
    
    tux > cat /etc/security/limits.conf | grep nproc

29.1.2 Existing Deployments

Note
Note: Embedded uaa in scf

The User Account and Authentication (uaa) Server is included as an optional feature of the scf Helm chart. This simplifies the Cloud Application Platform deployment process as a separate installation and/or upgrade of uaa is no longer a prerequisite to installing and/or upgrading scf.

It is important to note that:

  • This feature should only be used when uaa is not shared with other projects.

  • You cannot migrate from an existing external uaa to an embedded one. In this situation, enabling this feature during an upgrade will result in a single admin account.

To enable this feature, add the following to your scf-config-values.yaml.

enable:
  uaa: true

When deploying and/or upgrading scf, run helm install and/or helm upgrade and note that:

  • Installing and/or upgrading uaa using helm install suse/uaa ... and/or helm upgrade is no longer required.

  • It is no longer necessary to set the UAA_CA_CERT parameter. Previously, this parameter was passed the CA_CERT variable, which was assigned the CA certificate of uaa.

For existing SUSE Cloud Application Platform deployments, follow the steps below to redeploy SUSE Cloud Application Platform with nproc limits configured:

  1. Use helm upgrade to apply the change:

    Note
    Note: Setting UAA_CA_CERT

    Starting with SUSE Cloud Application Platform 1.5.2, you no longer need to set UAA_CA_CERT when using an external UAA with a certificate signed by a well known Certificate Authority (CA). It is only needed when you use an external UAA with either a certificate generated by the secret-generator or a self-signed certificate.

    If you need to set UAA_CA_CERT:

    1. Obtain your UAA secret and certificate:

      tux > SECRET=$(kubectl get pods --namespace uaa \
      --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
      
      tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
      --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
    2. Then pass --set "secrets.UAA_CA_CERT=${CA_CERT}" as part of your helm command.

    tux > helm upgrade susecf-scf suse/cf \
    --values scf-config-values.yaml \
    --version 2.20.3
  2. Monitor the deployment progress using the watch command:

    tux > watch --color 'kubectl get pods --namespace scf'
  3. Open a shell into any container. The command below opens a shell to the default container in the blobstore-0 pod:

    tux > kubectl exec --stdin --tty blobstore-0 --namespace scf -- env /bin/bash
  4. Use the vcap user identity:

    tux > su vcap
  5. Verify the maximum number of processes for the vcap user matches the limits you set:

    tux > ulimit -u
    
    tux > cat /etc/security/limits.conf | grep nproc
Print this page