Red Hat Summit4.9. Verifying pods after resolving a mismatch
Verify the security context constraint (SCC) and the SELinux label of both the pods by using the following verification steps.
Verification
Verify that the same SCC is assigned to the first pod by running the following command:
$ oc describe pod <pod_name_a> |grep -i scc1 - 1
- Replace
<pod_name_a>with the name of the first pod.
Example output
openshift.io/scc: restrictedVerify that the same SCC is assigned to first second pod by running the following command:
$ oc describe pod <pod_name_b> |grep -i scc1 - 1
- Replace
<pod_name_b>with the name of the second pod.
Example output
openshift.io/scc: restrictedVerify that the same SELinux label is applied to first pod by running the following command:
$ oc exec <pod_name_a> -- ls -laZ <pvc_mountpoint>1 - 1
- Replace
<pod_name_a>with the name of the first pod and replace<pvc_mountpoint>with the mount point within the first pod.
Example output
total 4 drwxrwsrwx. 2 root 1000670000 system_u:object_r:container_file_t:s0:c10,c26 19 Aug 29 18:17 . dr-xr-xr-x. 1 root root system_u:object_r:container_file_t:s0:c10,c26 61 Aug 29 18:16 .. -rw-rw-rw-. 1 1000670000 1000670000 system_u:object_r:container_file_t:s0:c10,c26 29 Aug 29 18:17 test1 [...]Verify that the same SELinux label is applied to second pod by running the following command:
$ oc exec <pod_name_b> -- ls -laZ <pvc_mountpoint>1 - 1
- Replace
<pod_name_b>with the name of the second pod and replace<pvc_mountpoint>with the mount point within the second pod.
Example output
total 4 drwxrwsrwx. 2 root 1000670000 system_u:object_r:container_file_t:s0:c10,c26 19 Aug 29 18:17 . dr-xr-xr-x. 1 root root system_u:object_r:container_file_t:s0:c10,c26 61 Aug 29 18:16 .. -rw-rw-rw-. 1 1000670000 1000670000 system_u:object_r:container_file_t:s0:c10,c26 29 Aug 29 18:17 test1 [...]
change
@@ -1,115 +0,0 @@
// Module included in the following assemblies:
//
// * storage/understanding-persistent-storage.adoc
//* microshift_storage/understanding-persistent-storage-microshift.adoc4.9.1. Persistent volume claims
Each PersistentVolumeClaim object contains spec and status fields, which are the specification and status of the persistent volume claim (PVC), for example:
PersistentVolumeClaim object definition example
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
storageClassName: gold
status:
...4.9.2. Storage classes
Claims can optionally request a specific storage class by specifying the storage class’s name in the storageClassName attribute. Only PVs of the requested class, ones with the same storageClassName as the PVC, can be bound to the PVC. The cluster administrator can configure dynamic provisioners to service one or more storage classes. The cluster administrator can create a PV on-demand that matches the specifications in the PVC.
The cluster administrator can also set a default storage class for all PVCs. When a default storage class is configured, the PVC must explicitly ask for StorageClass or storageClassName annotations set to "" to be bound to a PV without a storage class.
If more than one storage class is marked as default, a PVC can only be created if the storageClassName is explicitly specified. Therefore, only one storage class should be set as the default.
4.9.3. Access modes
Claims use the same conventions as volumes when requesting storage with specific access modes.
4.9.4. Resources
Claims, such as pods, can request specific quantities of a resource. In this case, the request is for storage. The same resource model applies to volumes and claims.
4.9.5. Claims as volumes
Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the pod using the claim. The cluster finds the claim in the pod’s namespace and uses it to get the PersistentVolume backing the claim. The volume is mounted to the host and into the pod, for example:
Mount volume to the host and into the pod example
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim - 1
- Path to mount the volume inside the pod.
- 2
- Name of the volume to mount. Do not mount to the container root,
/, or any path that is the same in the host and the container. This can corrupt your host system if the container is sufficiently privileged, such as the host/dev/ptsfiles. It is safe to mount the host by using/host. - 3
- Name of the PVC, that exists in the same namespace, to use.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}