Deploying Docker Registry on Kubernetes Quiz

Explore the fundamental steps to deploy and secure a private Docker Registry on a Kubernetes cluster, including persistent storage and self-signed certificates. Ideal for cloud and DevOps practitioners seeking hands-on knowledge.

1. Purpose of Deploying Local Docker Registry

   What is a primary reason for deploying a Docker Registry within a Kubernetes cluster?

   1. To store and retrieve custom images for cluster use
   2. To provide built-in monitoring services
   3. To automatically update Kubernetes versions
   4. To offer database services

   Explanation: Deploying a Docker Registry allows storage and retrieval of custom images, supporting scenarios like air-gapped clusters or cluster-specific images. Built-in monitoring, automatic Kubernetes updates, and database services are unrelated to the Docker Registry's core function.

2. Creating TLS Secrets

   Which Kubernetes resource should be used to store a self-signed certificate and private key for securing the Docker Registry with TLS?

   1. ServiceAccount
   2. ConfigMap
   3. PersistentVolume
   4. Secret of type tls

   Explanation: A Secret of type tls is designed for storing certificates and keys, enabling secure configuration for components like Docker Registry. ConfigMaps handle general configuration data. PersistentVolumes provide storage, and ServiceAccounts manage pod identities.

3. Persistent Storage Configuration

   Why is it recommended to set up a PersistentVolumeClaim (PVC) for the Docker Registry in Kubernetes?

   1. To manage pod network policies automatically
   2. To allow containers to run as root
   3. To preserve image data if the pod is rescheduled
   4. To reduce container startup times

   Explanation: A PVC ensures image data persists beyond pod lifecycle events, preventing data loss. It does not handle network policies, reduce startup times, or control user permissions within containers.

4. Mounting Volumes in Deployment

   When defining the container spec for the Docker Registry deployment, how should the TLS certificate and key be made available inside the container?

   1. By encoding them into the registry image
   2. By downloading directly from a public URL
   3. By mounting a secret volume at a specified directory
   4. By defining environment variables with certificate content

   Explanation: Mounting the TLS secret as a volume exposes the key and certificate within the container in a secure and manageable way. Environment variables are unsuitable for large binary data, downloading from a URL is insecure, and embedding secrets in the image is not recommended.

5. Exposing the Registry Service

   What must be specified in the self-signed certificate's subjectAltName to support external communication with the Docker Registry via a Kubernetes LoadBalancer?

   1. The hostname of the cluster master
   2. The external IP address assigned by the LoadBalancer
   3. The internal pod name
   4. The default gateway address

   Explanation: Including the external IP in the subjectAltName ensures TLS connections succeed when accessed over the assigned address. Internal pod names, gateway addresses, or cluster master hostnames do not enable proper certificate validation for external access.