Chapter 2. Working with pods

Procedure

1. In the OpenShift Container Platform console, navigate to Workloads Pods or navigate to the pod through the resource you want to investigate.

   Note

   Some resources, such as builds, do not have pods to query directly. In such instances, you can locate the Logs link on the Details page for the resource.

2. Select a project from the drop-down menu.
3. Click the name of the pod you want to investigate.
4. Click Logs.

1. Create a YAML file with the an object definition similar to the following:

   apiVersion: policy/v1 

   1

   
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2  

   2

   
     selector:  

   3

   
       matchLabels:
         name: my-pod

   1

   PodDisruptionBudget is part of the policy/v1 API group.

   2

   The minimum number of pods that must be available simultaneously. This can be either an integer or a string specifying a percentage, for example, 20%.

   3

   A label query over a set of resources. The result of matchLabels and matchExpressions are logically conjoined. Leave this parameter blank, for example selector {}, to select all pods in the project.

   Or:

   apiVersion: policy/v1 

   1

   
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     maxUnavailable: 25% 

   2

   
     selector: 

   3

   
       matchLabels:
         name: my-pod

   1

   PodDisruptionBudget is part of the policy/v1 API group.

   2

   The maximum number of pods that can be unavailable simultaneously. This can be either an integer or a string specifying a percentage, for example, 20%.

   3

   A label query over a set of resources. The result of matchLabels and matchExpressions are logically conjoined. Leave this parameter blank, for example selector {}, to select all pods in the project.

2. Run the following command to add the object to project:

   $ oc create -f </path/to/file> -n <project_name>

Procedure

1. Create a YAML file that defines a

   PodDisruptionBudget

   object and specify the unhealthy pod eviction policy:

   Example pod-disruption-budget.yaml file

   apiVersion: policy/v1
   kind: PodDisruptionBudget
   metadata:
     name: my-pdb
   spec:
     minAvailable: 2
     selector:
       matchLabels:
         name: my-pod
     unhealthyPodEvictionPolicy: AlwaysAllow 

   1

   1

   Choose either IfHealthyBudget or AlwaysAllow as the unhealthy pod eviction policy. The default is IfHealthyBudget when the unhealthyPodEvictionPolicy field is empty.

2. Create the

   PodDisruptionBudget

   object by running the following command:

   $ oc create -f pod-disruption-budget.yaml

Procedure

1. In the Topology view, click the node to reveal the side pane.
2. From the Actions drop-down list, select Edit HorizontalPodAutoscaler to open the Edit Horizontal Pod Autoscaler form.
3. From the Edit Horizontal Pod Autoscaler form, edit the minimum and maximum pod limits and the CPU and memory usage, and click Save.

Procedure

1. In the Topology view, click the node to reveal the side panel.
2. From the Actions drop-down list, select Remove HorizontalPodAutoscaler.
3. In the confirmation window, click Remove to remove the HPA.

Procedure

1. Create a

   HorizontalPodAutoscaler

   object for an existing object:

   $ oc autoscale <object_type>/<name> \

   1

   
     --min <number> \

   2

   
     --max <number> \

   3

   
     --cpu-percent=<percent> 

   4

   1

   Specify the type and name of the object to autoscale. The object must exist and be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.

   2

   Optional: Specify the minimum number of replicas when scaling down.

   3

   Specify the maximum number of replicas when scaling up.

   4

   Specify the target average CPU use over all the pods, represented as a percent of requested CPU. If not specified or negative, a default autoscaling policy is used.

   For example, the following command shows autoscaling for the

   hello-node

   deployment object. The initial deployment requires 3 pods. The HPA object increases the minimum to 5. If CPU usage on the pods reaches 75%, the pods will increase to 7:

   $ oc autoscale deployment/hello-node --min=5 --max=7 --cpu-percent=75

2. Create the horizontal pod autoscaler:

   $ oc create -f <file-name>.yaml

Procedure

1. Create a YAML file similar to the following for an existing object:

   apiVersion: autoscaling/v2 

   1

   
   kind: HorizontalPodAutoscaler
   metadata:
     name: cpu-autoscale 

   2

   
     namespace: default
   spec:
     scaleTargetRef:
       apiVersion: apps/v1 

   3

   
       kind: Deployment 

   4

   
       name: example 

   5

   
     minReplicas: 1 

   6

   
     maxReplicas: 10 

   7

   
     metrics: 

   8

   
     - type: Resource
       resource:
         name: cpu 

   9

   
         target:
           type: AverageValue 

   10

   
           averageValue: 500m 

   11

   1

   Use the autoscaling/v2 API.

   2

   Specify a name for this horizontal pod autoscaler object.

   3

   Specify the API version of the object to scale:

   • For a

     Deployment

     ,

     ReplicaSet

     ,

     Statefulset

     object, use

     apps/v1

     .
   • For a

     ReplicationController

     , use

     v1

     .
   • For a

     DeploymentConfig

     , use

     apps.openshift.io/v1

     .

   4

   Specify the type of object. The object must be a Deployment, DeploymentConfig/dc, ReplicaSet/rs, ReplicationController/rc, or StatefulSet.

   5

   Specify the name of the object to scale. The object must exist.

   6

   Specify the minimum number of replicas when scaling down.

   7

   Specify the maximum number of replicas when scaling up.

   8

   Use the metrics parameter for memory use.

   9

   Specify cpu for CPU usage.

   10

   Set to AverageValue.

   11

   Set to averageValue with the targeted CPU value.

2. Create the horizontal pod autoscaler:

   $ oc create -f <file-name>.yaml

Procedure

1. Create a

   HorizontalPodAutoscaler

   object similar to the following for an existing object:

   apiVersion: autoscaling/v2 

   1

   
   kind: HorizontalPodAutoscaler
   metadata:
     name: memory-autoscale 

   2

   
     namespace: default
   spec:
     scaleTargetRef:
       apiVersion: apps/v1 

   3

   
       kind: Deployment 

   4

   
       name: example 

   5

   
     minReplicas: 1 

   6

   
     maxReplicas: 10 

   7

   
     metrics: 

   8

   
     - type: Resource
       resource:
         name: memory 

   9

   
         target:
           type: Utilization 

   10

   
           averageUtilization: 50 

   11

   
     behavior: 

   12

   
       scaleUp:
         stabilizationWindowSeconds: 180
         policies:
         - type: Pods
           value: 6
           periodSeconds: 120
         - type: Percent
           value: 10
           periodSeconds: 120
         selectPolicy: Max

   1

   Use the autoscaling/v2 API.

   2

   Specify a name for this horizontal pod autoscaler object.

   3

   Specify the API version of the object to scale:

   • For a ReplicationController, use

     v1

     .
   • For a DeploymentConfig, use

     apps.openshift.io/v1

     .
   • For a Deployment, ReplicaSet, Statefulset object, use

     apps/v1

     .

   4

   Specify the type of object. The object must be a Deployment, DeploymentConfig, ReplicaSet, ReplicationController, or StatefulSet.

   5

   Specify the name of the object to scale. The object must exist.

   6

   Specify the minimum number of replicas when scaling down.

   7

   Specify the maximum number of replicas when scaling up.

   8

   Use the metrics parameter for memory usage.

   9

   Specify memory for memory usage.

   10

   Set to Utilization.

   11

   Specify averageUtilization and a target average memory usage over all the pods, represented as a percent of requested memory. The target pods must have memory requests configured.

   12

   Optional: Specify a scaling policy to control the rate of scaling up or down.

2. Create the horizontal pod autoscaler by using a command similar to the following:

   $ oc create -f <file-name>.yaml

   For example:

   $ oc create -f hpa.yaml

   Example output

   horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

Procedure

1. Create a

   HorizontalPodAutoscaler

   object similar to the following for an existing object:

   apiVersion: autoscaling/v2 

   1

   
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-resource-metrics-memory 

   2

   
     namespace: default
   spec:
     scaleTargetRef:
       apiVersion: apps/v1 

   3

   
       kind: Deployment 

   4

   
       name: example 

   5

   
     minReplicas: 1 

   6

   
     maxReplicas: 10 

   7

   
     metrics: 

   8

   
     - type: Resource
       resource:
         name: memory 

   9

   
         target:
           type: AverageValue 

   10

   
           averageValue: 500Mi 

   11

   
     behavior: 

   12

   
       scaleDown:
         stabilizationWindowSeconds: 300
         policies:
         - type: Pods
           value: 4
           periodSeconds: 60
         - type: Percent
           value: 10
           periodSeconds: 60
         selectPolicy: Max

   1

   Use the autoscaling/v2 API.

   2

   Specify a name for this horizontal pod autoscaler object.

   3

   Specify the API version of the object to scale:

   • For a

     Deployment

     ,

     ReplicaSet

     , or

     Statefulset

     object, use

     apps/v1

     .
   • For a

     ReplicationController

     , use

     v1

     .
   • For a

     DeploymentConfig

     , use

     apps.openshift.io/v1

     .

   4

   Specify the type of object. The object must be a Deployment, DeploymentConfig, ReplicaSet, ReplicationController, or StatefulSet.

   5

   Specify the name of the object to scale. The object must exist.

   6

   Specify the minimum number of replicas when scaling down.

   7

   Specify the maximum number of replicas when scaling up.

   8

   Use the metrics parameter for memory usage.

   9

   Specify memory for memory usage.

   10

   Set the type to AverageValue.

   11

   Specify averageValue and a specific memory value.

   12

   Optional: Specify a scaling policy to control the rate of scaling up or down.

2. Create the horizontal pod autoscaler by using a command similar to the following:

   $ oc create -f <file-name>.yaml

   For example:

   $ oc create -f hpa.yaml

   Example output

   horizontalpodautoscaler.autoscaling/hpa-resource-metrics-memory created

1. Create a service account for the alternative recommender and bind that service account to the required cluster role:

   apiVersion: v1 

   1

   
   kind: ServiceAccount
   metadata:
     name: alt-vpa-recommender-sa
     namespace: <namespace_name>
   ---
   apiVersion: rbac.authorization.k8s.io/v1 

   2

   
   kind: ClusterRoleBinding
   metadata:
     name: system:example-metrics-reader
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:metrics-reader
   subjects:
   - kind: ServiceAccount
     name: alt-vpa-recommender-sa
     namespace: <namespace_name>
   ---
   apiVersion: rbac.authorization.k8s.io/v1 

   3

   
   kind: ClusterRoleBinding
   metadata:
     name: system:example-vpa-actor
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:vpa-actor
   subjects:
   - kind: ServiceAccount
     name: alt-vpa-recommender-sa
     namespace: <namespace_name>
   ---
   apiVersion: rbac.authorization.k8s.io/v1 

   4

   
   kind: ClusterRoleBinding
   metadata:
     name: system:example-vpa-target-reader-binding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:vpa-target-reader
   subjects:
   - kind: ServiceAccount
     name: alt-vpa-recommender-sa
     namespace: <namespace_name>

   1

   Creates a service account for the recommender in the namespace that displays the recommender.

   2

   Binds the recommender service account to the metrics-reader role. Specify the namespace for where to deploy the recommender.

   3

   Binds the recommender service account to the vpa-actor role. Specify the namespace for where to deploy the recommender.

   4

   Binds the recommender service account to the vpa-target-reader role. Specify the namespace for where to display the recommender.

2. To add the alternative recommender to the cluster, create a

   Deployment

   object similar to the following:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: alt-vpa-recommender
     namespace: <namespace_name>
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: alt-vpa-recommender
     template:
       metadata:
         labels:
           app: alt-vpa-recommender
       spec:
         containers: 

   1

   
         - name: recommender
           image: quay.io/example/alt-recommender:latest 

   2

   
           imagePullPolicy: Always
           resources:
             limits:
               cpu: 200m
               memory: 1000Mi
             requests:
               cpu: 50m
               memory: 500Mi
           ports:
           - name: prometheus
             containerPort: 8942
           securityContext:
             allowPrivilegeEscalation: false
             capabilities:
               drop:
                 - ALL
             seccompProfile:
               type: RuntimeDefault
         serviceAccountName: alt-vpa-recommender-sa 

   3

   
         securityContext:
           runAsNonRoot: true

   1

   Creates a container for your alternative recommender.

   2

   Specifies your recommender image.

   3

   Associates the service account that you created for the recommender.

   A new pod is created for the alternative recommender in the same namespace.

   $ oc get pods

   Example output

   NAME                                        READY   STATUS    RESTARTS   AGE
   frontend-845d5478d-558zf                    1/1     Running   0          4m25s
   frontend-845d5478d-7z9gx                    1/1     Running   0          4m25s
   frontend-845d5478d-b7l4j                    1/1     Running   0          4m25s
   vpa-alt-recommender-55878867f9-6tp5v        1/1     Running   0          9s

3. Configure a Vertical Pod Autoscaler Operator (VPA) custom resource (CR) that includes the name of the alternative recommender

   Deployment

   object.

   Example VPA CR to include the alternative recommender

   apiVersion: autoscaling.k8s.io/v1
   kind: VerticalPodAutoscaler
   metadata:
     name: vpa-recommender
     namespace: <namespace_name>
   spec:
     recommenders:
       - name: alt-vpa-recommender 

   1

   
     targetRef:
       apiVersion: "apps/v1"
       kind:       Deployment 

   2

   
       name:       frontend

   1

   Specifies the name of the alternative recommender deployment.

   2

   Specifies the name of an existing workload object you want this VPA to manage.

Procedure

1. Create a

   Secret

   object in a YAML file on a control plane node.

   For example:

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysecret
   type: Opaque 

   1

   
   data:
     username: <username>
     password: <password>

   1

   Specifies an opaque secret.

2. Use the following command to create a

   Secret

   object:

   $ oc create -f <filename>.yaml

3. To use the secret in a pod:

   1. Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
   2. Create the pod, which consumes the secret as an environment variable or as a file (using a

      secret

      volume), as shown in the "Understanding how to create secrets" section.

Procedure

1. Create a

   Secret

   object in a YAML file on a control plane node:

   Example secret object:

   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-sa-sample
     annotations:
       kubernetes.io/service-account.name: "sa-name" 

   1

   
   type: kubernetes.io/service-account-token 

   2

   1

   Specifies an existing service account name. If you are creating both the ServiceAccount and the Secret objects, create the ServiceAccount object first.

   2

   Specifies a service account token secret.

2. Use the following command to create the

   Secret

   object:

   $ oc create -f <filename>.yaml

3. To use the secret in a pod:

   1. Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
   2. Create the pod, which consumes the secret as an environment variable or as a file (using a

      secret

      volume), as shown in the "Understanding how to create secrets" section.

Procedure

1. Create a

   Secret

   object in a YAML file on a control plane node:

   Example secret object

   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-basic-auth
   type: kubernetes.io/basic-auth 

   1

   
   data:
   stringData: 

   2

   
     username: admin
     password: <password>

   1

   Specifies a basic authentication secret.

   2

   Specifies the basic authentication values to use.

2. Use the following command to create the

   Secret

   object:

   $ oc create -f <filename>.yaml

3. To use the secret in a pod:

   1. Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
   2. Create the pod, which consumes the secret as an environment variable or as a file (using a

      secret

      volume), as shown in the "Understanding how to create secrets" section.

Procedure

1. Create a

   Secret

   object in a YAML file on a control plane node:

   Example secret object:

   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-ssh-auth
   type: kubernetes.io/ssh-auth 

   1

   
   data:
     ssh-privatekey: | 

   2

   
             MIIEpQIBAAKCAQEAulqb/Y ...

   1

   Specifies an SSH authentication secret.

   2

   Specifies the SSH key/value pair as the SSH credentials to use.

2. Use the following command to create the

   Secret

   object:

   $ oc create -f <filename>.yaml

3. To use the secret in a pod:

   1. Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
   2. Create the pod, which consumes the secret as an environment variable or as a file (using a

      secret

      volume), as shown in the "Understanding how to create secrets" section.

Procedure

1. Create a

   Secret

   object in a YAML file on a control plane node.

   Example Docker configuration secret object

   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-docker-cfg
     namespace: my-project
   type: kubernetes.io/dockerconfig 

   1

   
   data:
     .dockerconfig:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 

   2

   1

   Specifies that the secret is using a Docker configuration file.

   2

   The output of a base64-encoded Docker configuration file

   Example Docker configuration JSON secret object

   apiVersion: v1
   kind: Secret
   metadata:
     name: secret-docker-json
     namespace: my-project
   type: kubernetes.io/dockerconfig 

   1

   
   data:
     .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 

   2

   1

   Specifies that the secret is using a Docker configuration JSONfile.

   2

   The output of a base64-encoded Docker configuration JSON file

2. Use the following command to create the

   Secret

   object

   $ oc create -f <filename>.yaml

3. To use the secret in a pod:

   1. Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
   2. Create the pod, which consumes the secret as an environment variable or as a file (using a

      secret

      volume), as shown in the "Understanding how to create secrets" section.

Procedure

1. Navigate to Workloads Secrets.

2. Click Create From YAML.

   1. Edit the YAML manually to your specifications, or drag and drop a file into the YAML editor. For example:

      apiVersion: v1
      kind: Secret
      metadata:
        name: example
        namespace: <namespace>
      type: Opaque 

      1

      
      data:
        username: <base64 encoded username>
        password: <base64 encoded password>
      stringData: 

      2

      
        hostname: myapp.mydomain.com

      1

      This example specifies an opaque secret; however, you may see other secret types such as service account token secret, basic authentication secret, SSH authentication secret, or a secret that uses Docker configuration.

      2

      Entries in the stringData map are converted to base64 and the entry will then be moved to the data map automatically. This field is write-only; the value will only be returned via the data field.

3. Click Create.

4. Click Add Secret to workload.

   1. From the drop-down menu, select the workload to add.
   2. Click Save.

1. Edit the

   Pod

   spec for your service.

2. Add the

   service.beta.openshift.io/serving-cert-secret-name

   annotation with the name you want to use for your secret.

   kind: Service
   apiVersion: v1
   metadata:
     name: my-service
     annotations:
         service.beta.openshift.io/serving-cert-secret-name: my-cert 

   1

   
   spec:
     selector:
       app: MyApp
     ports:
     - protocol: TCP
       port: 80
       targetPort: 9376

   The certificate and key are in PEM format, stored in

   tls.crt

   and

   tls.key

   respectively.

3. Create the service:

   $ oc create -f <file-name>.yaml

4. View the secret to make sure it was created:

   1. View a list of all secrets:

      $ oc get secrets

      Example output

      NAME                     TYPE                                  DATA      AGE
      my-cert                  kubernetes.io/tls                     2         9m

   2. View details on your secret:

      $ oc describe secret my-cert

      Example output

      Name:         my-cert
      Namespace:    openshift-console
      Labels:       <none>
      Annotations:  service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
                    service.beta.openshift.io/originating-service-name: my-service
                    service.beta.openshift.io/originating-service-uid: 640f0ec3-afc2-4380-bf31-a8c784846a11
                    service.beta.openshift.io/expiry: 2023-03-08T23:22:40Z
      
      Type:  kubernetes.io/tls
      
      Data
      ====
      tls.key:  1679 bytes
      tls.crt:  2595 bytes

5. Edit your

   Pod

   spec with that secret.

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-service-pod
   spec:
     containers:
     - name: mypod
       image: redis
       volumeMounts:
       - name: my-container
         mountPath: "/etc/my-path"
     volumes:
     - name: my-volume
       secret:
         secretName: my-cert
         items:
         - key: username
           path: my-group/my-username
           mode: 511

   When it is available, your pod will run. The certificate will be good for the internal service DNS name,

   <service.name>.<service.namespace>.svc

   .

   The certificate/key pair is automatically replaced when it gets close to expiration. View the expiration date in the

   service.beta.openshift.io/expiry

   annotation on the secret, which is in RFC3339 format.
   Note

   In most cases, the service DNS name

   <service.name>.<service.namespace>.svc

   is not externally routable. The primary use of

   <service.name>.<service.namespace>.svc

   is for intracluster or intraservice communication, and with re-encrypt routes.