Red Hat OpenShift Administration II: Configuring a Production Cluster
Deploy and update an application by applying different Kustomize overlays that are stored in a Git server.
Outcomes
Deploy an application by using Kustomize from provided files.
Apply an application update that changes a deployment.
Deploy an overlay of the application that increases the number of replicas.
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 declarative-kustomize
Instructions
Clone the
v1.1.0version of the application. Because this repository uses Git branches to represent application versions, you must use thev1.1.0branch.Clone the repository from the following URL:
https://git.ocp4.example.com/developer/declarative-kustomize.gitChange to the
~/DO280/labs/declarative-kustomizedirectory.[student@workstation ~]$
cd DO280/labs/declarative-kustomize[student@workstation declarative-kustomize]$Clone the initial version of the application.
[student@workstation declarative-kustomize]$
git clone \ https://git.ocp4.example.com/developer/declarative-kustomize.git --branch v1.1.0Cloning into 'declarative-kustomize'... ...output omitted...Change to the repository directory.
[student@workstation declarative-kustomize]$
cd declarative-kustomize
Examine the first version of the application.
Use the
treecommand to review the structure of the repository.[student@workstation declarative-kustomize]$
tree. ├── base │ ├── database
│ │ ├── configmap.yaml
│ │ ├── deployment.yaml
│ │ ├── kustomization.yaml
│ │ └── service.yaml
│ ├── exoplanets 
│ │ ├── deployment.yaml
│ │ ├── kustomization.yaml
│ │ ├── route.yaml
│ │ └── service.yaml
│ └── kustomization.yaml 
└── README.md
3 directories, 10 files The
databasebase defines resources to deploy a database. The
exoplanetsbase defines resources to deploy an application that uses the database. The repository has a
kustomization.yamlfile at the root, which uses two other bases.Examine the
base/kustomization.yamlfile.[student@workstation declarative-kustomize]$
cat base/kustomization.yamlkind: Kustomization resources:
- database
- exoplanets
secretGenerator:
- name: db-secrets
literals:
- DB_ADMIN_PASSWORD=postgres
- DB_NAME=database
- DB_PASSWORD=password
- DB_USER=user
configMapGenerator:
- name: db-config
literals:
- DB_HOST=database
- DB_PORT=5432 The
base/kustomization.yamlfile uses the other two bases. The base also uses generators to provide configuration for the two deployments in the application.
Deploy the
basedirectory of the repository to a newdeclarative-kustomizeproject. Verify that thev1.1.0version of the application is available athttp://exoplanets-declarative-kustomize.apps.ocp4.example.com.Log in to the OpenShift cluster as the
developeruser with thedeveloperpassword.[student@workstation declarative-kustomize]$
oc login -u developer -p developer \ https://api.ocp4.example.com:6443Login successful. ...output omitted...Create the
declarative-kustomizeproject.[student@workstation declarative-kustomize]$
oc new-project declarative-kustomize...output omitted...Use the
oc apply -kcommand to deploy the application with Kustomize.[student@workstation declarative-kustomize]$
oc apply -k baseconfigmap/database created configmap/db-config-2d7thbcgkc created secret/db-secrets-55cbgc8c6m created service/database created service/exoplanets created deployment.apps/database created deployment.apps/exoplanets created route.route.openshift.io/exoplanets createdUse the
watchcommand to wait until the workloads are running.[student@workstation declarative-kustomize]$
watch oc get allNAME READY STATUS RESTARTS AGE pod/database-55d6c77787-47649 1/1 Running 0 57s pod/exoplanets-d6f57869d-jhkhc 1/1 Running 2 (54s ago) 57s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/database ClusterIP 172.30.236.123 <none> 5432/TCP 57s service/exoplanets ClusterIP 172.30.248.130 <none> 8080/TCP 57s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/database 1/1 1 1 57s deployment.apps/exoplanets 1/1 1 1 57s NAME DESIRED CURRENT READY AGE replicaset.apps/database-55d6c77787 1 1 1 57s replicaset.apps/exoplanets-d6f57869d 1 1 1 57s NAME HOST/PORT ... route.route.openshift.io/exoplanets exoplanets-declarative-kustomize.apps.ocp4.example.com ...Press Ctrl+C to exit the
watchcommand.Open a web browser and navigate to
http://exoplanets-declarative-kustomize.apps.ocp4.example.com.
The browser displays the
v1.1.0version of the application.
Change to the
v1.1.1version of the application and examine the changes.Change to the
v1.1.1branch.[student@workstation declarative-kustomize]$
git checkout v1.1.1branch 'v1.1.1' set up to track 'origin/v1.1.1'. Switched to a new branch 'v1.1.1'Use the
git showcommand to display the last commit.[student@workstation declarative-kustomize]$
git show...output omitted... diff --git a/base/exoplanets/deployment.yaml b/base/exoplanets/deployment.yaml index 8bc4cf9..8389b69 100644 --- a/base/exoplanets/deployment.yaml +++ b/base/exoplanets/deployment.yaml @@ -23,7 +23,7 @@ spec: name: exoplanets - secretRef: name: exoplanets- image: registry.ocp4.example.com:8443/redhattraining/exoplanets:v1.1.0+ image: registry.ocp4.example.com:8443/redhattraining/exoplanets:v1.1.1imagePullPolicy: Always livenessProbe: httpGet:The
v1.1.1version updates the application to thev1.1.1image.
Deploy the updated application and verify that the URL now displays the
v1.1.1version.Use the
oc apply -kcommand to execute the changes.[student@workstation declarative-kustomize]$
oc apply -k base...output omitted...Use the
watchcommand to wait until the application redeploys.[student@workstation declarative-kustomize]$
watch oc get allNAME READY STATUS RESTARTS AGE pod/database-55d6c77787-47649 1/1 Running 0 57s pod/exoplanets-d6f57869d-jhkhc 1/1 Running 2 (54s ago) 57s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/database ClusterIP 172.30.236.123 <none> 5432/TCP 57s service/exoplanets ClusterIP 172.30.248.130 <none> 8080/TCP 57s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/database 1/1 1 1 57s deployment.apps/exoplanets 1/1 1 1 57s NAME DESIRED CURRENT READY AGE replicaset.apps/database-55d6c77787 1 1 1 57s replicaset.apps/exoplanets-d6f57869d 1 1 1 57s NAME HOST/PORT ... route.route.openshift.io/exoplanets exoplanets-declarative-kustomize.apps.ocp4.example.com ...Press Ctrl+C to exit the
watchcommand.Open a web browser and navigate to
http://exoplanets-declarative-kustomize.apps.ocp4.example.com.
The browser displays the
v1.1.1version of the application.
Change to the
v1.1.2version of the application and examine the changes.Change to the
v1.1.2branch.[student@workstation declarative-kustomize]$
git checkout v1.1.2branch 'v1.1.2' set up to track 'origin/v1.1.2'. Switched to a new branch 'v1.1.2'Use the
git showcommand to display the last commit.[student@workstation declarative-kustomize]$
git show...output omitted... diff --git a/base/kustomization.yaml b/base/kustomization.yaml index fdf129a..8de16e8 100644 --- a/base/kustomization.yaml +++ b/base/kustomization.yaml @@ -7,7 +7,7 @@ secretGenerator: literals: - DB_ADMIN_PASSWORD=postgres - DB_NAME=database- - DB_PASSWORD=password+ - DB_PASSWORD=newpassword- DB_USER=user configMapGenerator: - name: db-configThe
v1.1.2version updates the base kustomization. This update changes the password that the database uses. This change is possible because the sample application re-creates the database on startup.List the secrets in the namespace.
[student@workstation declarative-kustomize]$
oc get secretNAME TYPE DATA AGE builder-dockercfg-qwn4v kubernetes.io/dockercfg 1 4m31s builder-token-z754n kubernetes.io/service-account-token 4 4m31sdb-secrets-55cbgc8c6m Opaque 4 4m28sdefault-dockercfg-w4v89 kubernetes.io/dockercfg 1 4m31s default-token-zw89c kubernetes.io/service-account-token 4 4m31s deployer-dockercfg-l8sct kubernetes.io/dockercfg 1 4m31s deployer-token-knvhb kubernetes.io/service-account-token 4 4m31sWhen creating a secret, Kustomize appends a hash to the secret name.
Extract the contents of the secret. The name of the secret can change in your environment. Use the output from a previous step to learn the name of the secret.
[student@workstation declarative-kustomize]$
oc extract \ secret/db-secrets-# DB_PASSWORD password # DB_USER user # DB_ADMIN_PASSWORD postgres # DB_NAME database55cbgc8c6m--to=-
Deploy the updated application.
Use the
oc apply -kcommand to execute the changes.[student@workstation declarative-kustomize]$
oc apply -k baseconfigmap/database unchanged configmap/db-config-2d7thbcgkc unchangedsecret/db-secrets-6h668tk789 createdservice/database unchanged service/exoplanets unchangeddeployment.apps/database configureddeployment.apps/exoplanets configuredroute.route.openshift.io/exoplanets configuredBecause the password is different, Kustomize creates another secret. Kustomize also updates the two deployments that use the secret to use the new secret.
Use the
watchcommand to wait until the application redeploys.[student@workstation declarative-kustomize]$
watch oc get allNAME READY STATUS RESTARTS AGE pod/database-55d6c77787-47649 1/1 Running 0 57s pod/exoplanets-d6f57869d-jhkhc 1/1 Running 2 (54s ago) 57s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/database ClusterIP 172.30.236.123 <none> 5432/TCP 57s service/exoplanets ClusterIP 172.30.248.130 <none> 8080/TCP 57s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/database 1/1 1 1 57s deployment.apps/exoplanets 1/1 1 1 57s NAME DESIRED CURRENT READY AGE replicaset.apps/database-55d6c77787 1 1 1 57s replicaset.apps/exoplanets-d6f57869d 1 1 1 57s NAME HOST/PORT ... route.route.openshift.io/exoplanets exoplanets-declarative-kustomize.apps.ocp4.example.com ...Press Ctrl+C to exit the
watchcommand.Open a web browser and navigate to
http://exoplanets-declarative-kustomize.apps.ocp4.example.com.The browser continues showing the
v1.1.1version of the application.Examine the deployment.
[student@workstation declarative-kustomize]$
oc get deployment exoplanets \ -o jsonpath='{.spec.template.spec.containers[0].envFrom}{"\n"}'[{"configMapRef":{"name":"db-config-2d7thbcgkc"}},{"secretRef":{"name":"db-secrets-6h668tk789"}}]The deployment uses the new secret.
Examine the secret. Use the name of the secret from a previous step.
[student@workstation declarative-kustomize]$
oc extract \ secret/db-secrets-# DB_ADMIN_PASSWORD postgres # DB_NAME database # DB_PASSWORD6h668tk789--to=-newpassword# DB_USER userThe deployment uses the changed password.
Change to the
v1.1.3version of the application and examine the changes.Change to the
v1.1.3branch.[student@workstation declarative-kustomize]$
git checkout v1.1.3branch 'v1.1.3' set up to track 'origin/v1.1.3'. Switched to a new branch 'v1.1.3'Use the
git showcommand to display the last commit.[student@workstation declarative-kustomize]$
git show...output omitted... diff --git a/overlays/production/kustomization.yaml b/overlays/production/kustomization.yaml new file mode 100644 index 0000000..73bb7fe --- /dev/null +++ b/overlays/production/kustomization.yaml @@ -0,0 +1,8 @@ +kind: Kustomization +resources: +- ../../base/ +patches: +- path: patch-replicas.yaml + target: + kind: Deployment + name: exoplanets diff --git a/overlays/production/patch-replicas.yaml b/overlays/production/patch-replicas.yaml new file mode 100644 index 0000000..a025aa0 --- /dev/null +++ b/overlays/production/patch-replicas.yaml @@ -0,0 +1,6 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: exoplanets +spec: + replicas: 2The
v1.1.3version adds aproductionoverlay that increases the number of replicas.
Deploy the updated application and verify the number of replicas.
Use the
oc apply -kcommand to execute the changes.[student@workstation declarative-kustomize]$
oc apply -k overlays/production...output omitted...Use the
watchcommand to wait until the application redeploys.[student@workstation declarative-kustomize]$
watch oc get allNAME READY STATUS RESTARTS AGE pod/database-7dfb559cf7-rvxhx 1/1 Running 0 11m pod/exoplanets-957bb5b48-5xl2d 1/1 Running 2 (11m ago) 11m pod/exoplanets-957bb5b48-mgbrx 1/1 Running 0 19s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/database ClusterIP 172.30.87.214 <none> 5432/TCP 19m service/exoplanets ClusterIP 172.30.25.65 <none> 8080/TCP 19m NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/database 1/1 1 1 19m deployment.apps/exoplanets 2/2 2 2 19m NAME DESIRED CURRENT READY AGE replicaset.apps/database-7dfb559cf7 1 1 1 11m replicaset.apps/database-d4cd8dcc 0 0 0 19m replicaset.apps/exoplanets-6c7b4bb44c 0 0 0 19m replicaset.apps/exoplanets-7ccb754c8b 0 0 0 18m replicaset.apps/exoplanets-957bb5b48 2 2 2 11m NAME HOST/PORT ... route.route.openshift.io/exoplanets exoplanets-declarative-kustomize.apps.ocp4.example.com ...Press Ctrl+C to exit the
watchcommand. After you run the command, the application has two replicas.
Delete the application.
Use the
oc delete -kcommand to delete the resources that Kustomize manages.[student@workstation declarative-kustomize]$
oc delete -k base# Warning: 'bases' is deprecated. Please use 'resources' instead. Run 'kustomize edit fix' to update your Kustomization automatically. configmap "database" deleted configmap "db-config-2d7thbcgkc" deleted secret "db-secrets-h9hdmt2g79" deleted service "database" deleted service "exoplanets" deleted deployment.apps "database" deleted deployment.apps "exoplanets" deleted route.route.openshift.io "exoplanets" deletedChange to the home directory.
[student@workstation declarative-kustomize]$
cd[student@workstation ~]$
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.
1
3
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.
5
3
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!
3
4
1334