DO280 - ch02s05

Bookmark this page

Lab: Deploy Packaged Applications

Deploy and update applications from resource manifests that are packaged for sharing and distribution.

Outcomes

Deploy an application and its dependencies from resource manifests that are packaged as a Helm chart.
Update the application to a later version by using the Helm chart.
Use a container image in a private container registry instead of a public registry.
Customize the deployment to add resource requests and limits.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command ensures that the cluster API is reachable.

[student@workstation ~]$ lab start packaged-review

Instructions

Log in to the cluster as the developer user with the developer password. Create the packaged-review and packaged-review-prod projects.

[student@workstation ~]$ oc login -u developer -p developer \
  https://api.ocp4.example.com:6443

Create the packaged-review project.

[student@workstation ~]$ oc new-project packaged-review
Now using project "packaged-review" on server ...
...output omitted...

Create the packaged-review-prod project.

[student@workstation ~]$ oc new-project packaged-review-prod
Now using project "packaged-review-prod" on server ...
...output omitted...

Add the classroom Helm repository at the http://helm.ocp4.example.com/charts URL and examine its contents.
Use the helm repo list command to list the repositories that are configured for the student user.
[student@workstation ~]$ helm repo list NAME URL do280-repo http://helm.ocp4.example.com/charts
If the do280-repo repository is present, then continue to the next step. Otherwise, add the repository.
[student@workstation ~]$ helm repo add \ do280-repo http://helm.ocp4.example.com/charts "do280-repo" has been added to your repositories
Use the helm search command to list all the chart versions in the repository.
The etherpad chart has versions 0.0.6 and 0.0.7. This chart is a copy of a chart from the https://github.com/redhat-cop/helm-charts repository.
[student@workstation ~]$ helm search repo --versions NAME CHART VERSION APP VERSION DESCRIPTION do280-repo/etherpad 0.0.7 latest ... do280-repo/etherpad 0.0.6 latest ... ...output omitted...

Install the 0.0.6 version of the etherpad chart on the packaged-review namespace, with the test release name. Use the registry.ocp4.example.com:8443/etherpad/etherpad:1.8.17 image in the offline classroom registry.

Create a values-test.yaml file with the image repository, name, and tag.

Field	Value
`image.repository`	`registry.ocp4.example.com:8443/etherpad`
`image.name`	`etherpad`
`image.tag`	`1.8.17`

Switch to the packaged-review project.

[student@workstation ~]$ oc project packaged-review
Now using project "packaged-review" on server ...

Examine the values of the chart.

You can configure the image, the deployment resources, and other values. By default, the chart creates a route.

[student@workstation ~]$ helm show values do280-repo/etherpad --version 0.0.6
# Default values for etherpad.
replicaCount: 1

defaultTitle: "Labs Etherpad"
defaultText: "Assign yourself a user and share your ideas!"

image:
  repository: etherpad  
  name:  
  tag:  
  pullPolicy: IfNotPresent

...output omitted...

route:
  enabled: true
  host: null  
  targetPort: http

...output omitted...

resources: {} 
...output omitted...

	The registry with the container image.
	Container image name.
	Container image tag.
	Hostname for the OpenShift route resource.
	The resource requests and limits for this workload. This value is set by default to `{}`, which indicates that it is an empty map.

With the default configuration, the chart uses the docker.io/etherpad/etherpad:latest container image.
This image is not suitable for the classroom environment. Use the registry.ocp4.example.com:8443/etherpad/etherpad:1.8.17 container image instead.
Create a values-test.yaml file with the following content:
```
image:
  repository: registry.ocp4.example.com:8443/etherpad
  name: etherpad
  tag: 1.8.17
```

Install the etherpad chart in the packaged-review namespace.

Use the values-test.yaml file that you created in the previous step.
Use test as the release name.

[student@workstation ~]$ helm install test do280-repo/etherpad \
  -f values-test.yaml --version 0.0.6
NAME: test
LAST DEPLOYED: Fri Jun 30 01:03:42 2023
NAMESPACE: packaged-review
STATUS: deployed
REVISION: 1
TEST SUITE: None

Use the helm list command to verify the installed version of the etherpad chart.

[student@workstation ~]$ helm list
NAME  NAMESPACE        REVISION  ...  STATUS    CHART           APP VERSION
test  packaged-review  1         ...  deployed  etherpad-0.0.6  latest

Verify that the pod is running and that the deployment is ready.

[student@workstation ~]$ oc get deployments,pods
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/test-etherpad   1/1     1            1           27s

NAME                                READY   STATUS    RESTARTS   AGE
pod/test-etherpad-c6657b556-4jh8z   1/1     Running   0          27s

Verify that the pod executes the specified container image.

[student@workstation ~]$ oc describe pods -n packaged-review | \
  egrep '^Name:|Image:'
Name:             test-etherpad-c6657b556-4jh8z
    Image:          registry.ocp4.example.com:8443/etherpad/etherpad:1.8.17

Get the route to obtain the application URL.

[student@workstation ~]$ oc get routes
NAME      HOST/PORT                      ...
test-etherpad test-etherpad-packaged-review.apps.ocp4.example.com ...

Open a web browser and navigate to the following URL to view the application page.
https://test-etherpad-packaged-review.apps.ocp4.example.com

Upgrade the etherpad application in the packaged-review namespace to the 0.0.7 version of the chart. Set the image tag for the deployment in the values-test.yaml file.

Field	Value
`image.tag`	`1.8.18`

Edit the values-test.yaml file and update the image tag value:

image:
  repository: registry.ocp4.example.com:8443/etherpad
  name: etherpad
  tag: 1.8.18

Use the helm search command to verify that the repository contains a more recent version of the etherpad chart.

[student@workstation ~]$ helm search repo --versions etherpad
NAME                 CHART VERSION  APP VERSION  DESCRIPTION
do280-repo/etherpad  0.0.7          latest       ...
do280-repo/etherpad  0.0.6          latest       ...

Use the helm upgrade command to upgrade to the latest version of the chart.

[student@workstation ~]$ helm upgrade test do280-repo/etherpad \
  -f values-test.yaml --version 0.0.7
Release "test" has been upgraded. Happy Helming!
NAME: test
LAST DEPLOYED: Fri Jun 30 01:05:07 2023
NAMESPACE: packaged-review
STATUS: deployed
REVISION: 2
TEST SUITE: None

Use the helm list command to verify the installed version of the etherpad chart.

[student@workstation ~]$ helm list
NAME  NAMESPACE        REVISION  ...  STATUS    CHART           APP VERSION
test  packaged-review  2         ...  deployed  etherpad-0.0.7  latest

Verify that the pod is running and that the deployment is ready.

[student@workstation ~]$ oc get deployments,pods
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/test-etherpad   1/1     1            1           3m31s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/test-etherpad-59d775b78f-ftmsz   1/1     Running   0          64s

Verify that the pod executes the updated container image.

[student@workstation ~]$ oc describe pods -n packaged-review | \
  egrep '^Name:|Image:'
Name:             test-etherpad-59d775b78f-ftmsz
    Image:          registry.ocp4.example.com:8443/etherpad/etherpad:1.8.18

Reload the test-etherpad application welcome page in the web browser.

Using version 0.0.6, create a second deployment of the chart in the packaged-review-prod namespace, with the prod release name. Copy the values-test.yaml file to the values-prod.yaml file, and set the route host.

Field	Value
`route.host`	`etherpad.apps.ocp4.example.com`

Access the application in the route URL to verify that it is working correctly.

https://etherpad.apps.ocp4.example.com

Switch to the packaged-review-prod project.

[student@workstation ~]$ oc project packaged-review-prod
Now using project "packaged-review-prod" on server ...

Copy the values-test.yaml file to values-prod.yaml.

[student@workstation ~]$ cp values-test.yaml values-prod.yaml

Set the route host in the values-prod.yaml file.

image:
  repository: registry.ocp4.example.com:8443/etherpad
  name: etherpad
  tag: 1.8.18
route:
  host: etherpad.apps.ocp4.example.com

Install the 0.0.6 version of the etherpad chart on the packaged-review-prod namespace.

Use the values-prod.yaml file that you edited in the previous step. Use prod as the release name.

[student@workstation ~]$ helm install prod do280-repo/etherpad \
  -f values-prod.yaml --version 0.0.6
NAME: prod
LAST DEPLOYED: Fri Jun 30 01:07:29 2023
NAMESPACE: packaged-review-prod
STATUS: deployed
REVISION: 1
TEST SUITE: None

Use the helm list command to verify the installed version of the etherpad chart.

[student@workstation ~]$ helm list
NAME  NAMESPACE             REVISION  ...  STATUS    CHART           APP VERSION
prod  packaged-review-prod  1         ...  deployed  etherpad-0.0.6  latest

Verify that the pod is running and that the deployment is ready.

[student@workstation ~]$ oc get deployments,pods
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/prod-etherpad   1/1     1            1           65s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/prod-etherpad-5947dfb987-9dclr   1/1     Running   0          65s

Verify that the pod executes the specified container image.

[student@workstation ~]$ oc describe pods -n packaged-review-prod | \
  egrep '^Name:|Image:'
Name:             pod/prod-etherpad-5947dfb987-9dclr
    Image:          registry.ocp4.example.com:8443/etherpad/etherpad:1.8.18

Verify the deployment by opening a web browser and navigating to the application URL. This URL corresponds to the host that you specified in the values-prod.yaml file. The application welcome page appears in the production URL.
https://etherpad.apps.ocp4.example.com

Add limits to the etherpad instance in the packaged-review-prod namespace. The chart values example contains comments that show the required format for this change. Set limits and requests for the deployment in the values-prod.yaml file. Use version 0.0.7 of the chart.

Field	Value
`resources.limits.memory`	`256Mi`
`resources.requests.memory`	`128Mi`

Edit the values-prod.yaml file. Configure the deployment to request 128 MiB of RAM, and limit RAM usage to 128 MiB.

image:
  repository: registry.ocp4.example.com:8443/etherpad
  name: etherpad
  tag: 1.8.18
route:
  host: etherpad.apps.ocp4.example.com
resources:
  limits:
     memory: 256Mi
  requests:
     memory: 128Mi

Use the helm upgrade command to upgrade to the latest version of the chart.

[student@workstation ~]$ helm upgrade prod do280-repo/etherpad \
  -f values-prod.yaml --version 0.0.7
Release "prod" has been upgraded. Happy Helming!
NAME: prod
LAST DEPLOYED: Fri Jun 30 01:09:04 2023
NAMESPACE: packaged-review-prod
STATUS: deployed
REVISION: 2
TEST SUITE: None

Verify that the pod is running and that the deployment is ready.

[student@workstation ~]$ oc get deployments,pods
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/prod-etherpad   1/1     1            1           3m14s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/prod-etherpad-6b7d9dffbc-f7cng   1/1     Running   0          36s

Examine the application pod from the production instance of the application to verify the configuration change.

[student@workstation ~]$ oc describe pods -n packaged-review-prod | \
  egrep -A1 '^Name:|Limits|Requests'
Name:             prod-etherpad-6b7d9dffbc-f7cng
Namespace:        packaged-review-prod
--
    Limits:
      memory:  256Mi
    Requests:
      memory:   128Mi

Examine the pod of the test instance of the application in the packaged-review namespace. This deployment uses the values from the values-test.yaml file that did not specify resource limits or requests. The pod in the packaged-review namespace does not have a custom resource allocation.
```
[student@workstation ~]$ oc describe pods -n packaged-review | \
  egrep -A1 '^Name:|Limits|Requests'
Name:             test-etherpad-59d775b78f-ftmsz
Namespace:        packaged-review
```

Use the helm list command to verify the installed version of the etherpad chart.

[student@workstation ~]$ helm list
NAME  NAMESPACE             REVISION  ...  STATUS    CHART           APP VERSION
prod  packaged-review-prod  2         ...  deployed  etherpad-0.0.7  latest

Reload the application welcome page in the web browser. The deployment continues working after you add the limits.

Remove the values-test.yaml and values-prod.yaml files.

[student@workstation ~]$ rm values-test.yaml values-prod.yaml

Evaluation

As the student user on the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the command until successful.

[student@workstation ~]$ lab grade packaged-review

Finish

As the student user on the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish packaged-review

Discuss Red Hat OpenShift Administration II: Configuring a Production Cluster

Go to community

Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280)

Haley_Ruccio

26 lip 2023

Configure, manage, and troubleshoot OpenShift clusters and containerized applicationsRed Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280) prepares OpenShift Cluster Administrators to perform daily administration tasks on clusters that host applications provided by internal teams and external vendors, enable self-service for cluster users with different roles, and deploy applications that require special permissions such as such as CI/CD tooling, performance monitoring, and security scanners. This course focuses on configuring multi-tenancy and security features of OpenShift as well as managing OpenShift add-ons based on operators.The skills you learn in this course can be applied using all versions of OpenShift, including Red Hat OpenShift on AWS (ROSA), Azure Red Hat OpenShift, and OpenShift Container Platform.This course is based on OpenShift Container Platform 4.12.5-10 Course TopicsDeploying packaged applications using manifests, templates, kustomize, and helm.Configuring authentication and authorization for users and applications.Protecting network traffic with network policies and exposing applications with proper network access.Deploying and managing applications using resources manifests.Enabling developer self-service of application projects.Managing OpenShift cluster updates and Kubernetes operator updates.Target AudienceSystem Administrators and Platform Operators interested in the ongoing management of OpenShift clusters, applications, users, and add-ons.Site Reliability Engineers interested in the ongoing maintenance and troubleshooting of Kubernetes clusters.System and Software Architects interested in understanding the security of an OpenShift cluster.Recommended TrainingTake our free assessment to gauge whether this offering is the best fit for your skills.Prerequisite: Red Hat OpenShift I: Containers & Kubernetes (DO180 v4.12), or equivalent skills deploying and managing Kubernetes applications using the OpenShift web console and command-line interfaces.Technology considerationsThis course requires internet access to access the cloud-based classroom environment that provides an OpenShift cluster and a remote administrator’s workstation.

476

About pod security standards and warnings

alexcorcoles

17 kwi 2023

(This material has been created with the inputs of instructors and other people. We are trying to get this material published as soon as possible to address some concerns with DO180 and DO280.)With the default configuration, any namespace that you create on OpenShift 4.12 has the following labels: pod-security.kubernetes.io/audit: restrictedpod-security.kubernetes.io/audit-version: v1.24pod-security.kubernetes.io/warn: restrictedpod-security.kubernetes.io/warn-version: v1.24 These labels activate auditing and warning of the restricted pod security standard. The Kubernetes documentation describes the restricted pod security standard. Pod security standards such as restricted are not directly related to security context constraints such as the restricted SCC.Kubernetes uses an admission controller to reject pods that do not comply with pod security standards. An admission controller is a Kubernetes component that inspects every Kubernetes resource before its creation, and acts before Kubernetes creates the resource. This action can include rejecting the creation of the resource, or modifying the resource.The pod security standards are policies that include properties that workloads must follow. For example, the restricted standard requires that containers set the securityContext.allowPrivilegeEscalation field to false.Pod security standards apply both to workloads, such as deployments and jobs, and to pods.When a pod is created, the admission controller inspects the container specifications and enumerates the fields that violate the pod security standard of the namespace. The admission controller inspects the pod-security labels in the namespace to decide which pod security standard to apply (restricted, baseline, or privileged), and which action to take on violations. Namespaces can audit, warn, or enforce pod security standard violations. When the pod-security.kubernetes.io/audit annotation is set to restricted, the admission controller prevents the creation of pods that violate the security standard. When the pod-security.kubernetes.io/audit and pod-security.kubernetes.io/warn annotations are defined in the project, the admission controller does not block the creation of pods, but registers audit events or warnings.The admission controller does not enforce pod security standards for workloads. If the namespace is configured to enforce a pod security standard, then you can create a violating workload. The admission controller enforces only pod security policies on pods.Cluster administrators can use pod security standards to ensure that pods and workloads in namespaces limit their privileges. By limiting privileges, cluster administrators can mitigate what malicious pods can do.The default configuration of user namespaces in OpenShift does not restrict any workload; it only notifies users when they create workloads that do not follow pod security standards that might be enforced in future OpenShift versions.Security Context ConstraintsOpenShift introduced security context constraints (SCC) before the introduction of pod security standards in Kubernetes. SCCs automatically make security modifications to pods when they are created. By default, the system:openshift:scc:restricted-v2 cluster role binding applies to all authenticated users, so regular user workloads use the restricted-v2 SCC. For example, when you execute the following command to create a workload without any security configuration, the SCC adds security configuration to the pods: [user@host ~]$ oc create deployment test --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx (You can add the --dry-run=client -o yaml options to view the deployment manifest. The deployment manifest does not contain the security properties, which are described later.)If you inspect the pods that the deployment created, the SCC makes the following changes: [user@host ~]$ oc get pod test-b8d5658b6-7bxfs -o yamlapiVersion: v1kind: Podmetadata: annotations:... output omitted... openshift.io/scc: restricted-v2 seccomp.security.alpha.kubernetes.io/pod: runtime/default...output omitted...spec: containers: - image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx imagePullPolicy: Always name: hello-world-nginx resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true runAsUser: 1000690000... output omitted... securityContext: fsGroup: 1000690000 seLinuxOptions: level: s0:c26,c20 seccompProfile: type: RuntimeDefault... output omitted... These restrictions satisfy the restricted pod security policy.The result of these defaults means that when creating a workload (such as a deployment) in a namespace without any customization, the restricted pod security standard applies, but the admission controller only warns and audits. If the workload does not satisfy the pod security standard, then the admission controller allows the workload to be created, but prints a message such as the following warning: Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "example" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "database" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "example" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") However, by default Kubernetes creates the deployment pods with the restricted-v2 SCC, with the restrictions that the previous warning included. Due to the following factors, workloads generate only a warning, and the pod security standard admission controller allows their pods:The pod security standard admission controller never enforces pod security standards on workloads (only on pods).By default, namespaces do not enforce pod security standards on pods.By default, regular workloads create pods by using the restricted-v2 SCC, which satisfies the restricted pod security standard.Even if future versions of OpenShift change the default namespace configuration to enforce the restricted pod security standard, users will continue to be able to create workloads without explicitly declaring the restrictions that the pod security standard requires, because the restricted-v2 SCC will apply such restrictions automatically.You can take the following approaches to handling pod security:For most workloads, the restricted-v2 SCC limits pod privileges adequately. When creating a workload, you receive the warning, but the workload creates pods and works correctly.You can also create your workloads by providing a full specification of the security constraints to apply, without relying on the SCC to provide the configuration. By following this approach, privileges are more explicit, and you have greater control, so you can adjust more precisely the specific privileges that are granted to workloads.When the restricted-v2 SCC and the default restricted pod security standard are not adequate for your workload, because either you require further privileges, or you need further restrictions, you must use an existing SCC, or create a custom SCC, and provide explicit security specifications. You can also adjust the namespace labels to choose a different pod security standard, and decide to audit, log, or enforce the standard.

1473

Welcome to the Red Hat OpenShift Administration II (DO280) group in the Red Hat Learning Community!

Deanna

17 kwi 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster!To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO280.Read more about Red Hat OpenShift Administration II here.Thanks!

1334

Revision: do280-4.14-08d11e1