V-260932

Discussion

When a failure occurs within MKE, preserving the state of MKE and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.

Check Content

When using Swarm orchestration, this check is Not Applicable.

Review the Kubernetes configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

Notes:
- The ReadWriteOnce access mode in the PVC means the volume can be mounted as read-write by a single node. Ensure the storage backend supports this mode.
- Adjust the sleep duration in the writer pod as needed.
- Ensure that the namespace and PVC names match the setup.

Steps to verify data durability:
1. Create a namespace to manage the testing:

apiVersion: v1
kind: Namespace
metadata:
  name: stig

2. PersistentVolumeClaim (PVC):
Ensure a PVC is created. If using a storage class like Longhorn, it would look similar to:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: stig-pvc
  namespace: stig
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn  # Replace with your storage class if different, e.g. NFS
  resources:
    requests:
      storage: 5Gi

3. Deploying the Initial Pod:
Create a pod that writes data to the PVC. This pod will use a simple loop to write data (e.g., timestamps) to a file on the mounted PVC. Example:

apiVersion: v1
kind: Pod
metadata:
  name: write-pod
  namespace: stig
spec:
  volumes:
    - name: log-storage
      persistentVolumeClaim:
        claimName: stig-pvc
  containers:
    - name: writer
      image: busybox
      command: ["/bin/sh", "-c"]
      args: ["while true; do date >> /data/logs.log; sleep 10; done"]
      volumeMounts:
        - name: log-storage
          mountPath: /data

4. Simulate Pod Failure:
After the pod has been writing data for some time, it can be deleted to simulate a failure by executing the following:

kubectl delete pod write-pod -n stig

5. Deploying a New Pod to Verify Data:
Deploy another pod that mounts the same PVC to verify that the data is still there.

apiVersion: v1
kind: Pod
metadata:
  name: read-pod
  namespace: stig
spec:
  volumes:
    - name: log-storage
      persistentVolumeClaim:
        claimName: stig-pvc
  containers:
    - name: reader
      image: busybox
      command: ["/bin/sh", "-c"]
      args: ["sleep infinity"]
      volumeMounts:
        - name: log-storage
          mountPath: /data

6. Verify Data Persistence:
Check the contents of the log file in the new pod to ensure that the data written by the first pod is still there by executing the following:

kubectl exec read-pod -n stig -- cat /data/logs.log

If there is no log data, this is a finding.