Skip to content

CKAD Self-Study Mod 1

In this module of the RX-M online CKAD prep course, we will be covering the core concepts and configuration topics identified by the CNCF CKAD Exam Curriculum. If you are not already familiar with the curriculum, take a moment to familiarize yourself as you will be required to demonstrate knowledge of each topic in order to pass the exam. 

rx-m-cloud.png

Basic Pods

Pods are the atomic unit of deployment in Kubernetes and are made up of one or more containers in different arrays in a PodSpec:

  • Containers (required) - long-running containers for applications, proxies, logging/monitoring sidecars, etc.
  • Init containers (optional) - bootstrapping containers that run once to bootstrap long-running app containers
  • Ephemeral containers (optional) - an alpha feature in Kubernetes, these containers can be added at runtime for ad hoc troubleshooting

 
A basic pod would contain a single container and could be created with yaml or imperatively:
 

$ kubectl run ckad-basic-pod --image=nginx:latest

 

Learn more about pods

SecurityContext

This is a setting in a PodSpec that enhances security for one or all of the containers in a pod and have the following settings:

  • Discretionary Access Control: define user ID (UID) and group ID (GID) settings for processes inside container
  • Security Enhanced Linux (SELinux): invoke predefined security labels
  • Linux Capabilities: coarse-grained control of system calls to the Linux kernel in a whitelist or blacklist
    • Marking a pod with privileged = true grants all capabilities
  • AppArmor: invoke predefined program profiles to restrict the capabilities of individual programs
  • Seccomp: Fine-grained control over a process’s system calls through the use of json policies
  • AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent

 
SecurityContext settings can be set for the pod and/or each container in the pod, for example:
 

apiVersion: v1
kind: Pod
metadata:
  name: ckad-training-pod
spec:
  securityContext:               # pod securitycontext
    fsGroup: 2000
  containers:
  - name: ckad-training-container
     image: nginx
     securityContext:            # container securitycontext
       capabilities:
        add: ["NET_ADMIN"]

 

Learn more about security contexts

Container resource requests and limits

Resource requests and limits are set on a per-container basis within a pod. By specifying a resource request we tell the Kubernetes scheduler the _minimum_ amount of each resource (CPU and memory) a container will need. By specifying limits, we set up cgroup constraints on the node where the process runs. An example of setting requests/limits looks like:

 

apiVersion: v1
kind: Pod
metadata:
  name: ckad-resource-pod
spec:
  containers:
  - name: ckad-resource-container
    image: my-app:v3.3
    resources:
      limits:
        cpu: "1"
        memory: “1Gi”
      requests:
        cpu: "0.5"
        memory: “500Mi”

 

Learn more about pod resource requests/limits

ConfigMaps

ConfigMaps are decoupled configuration artifacts keeping containerized applications portable.

The ConfigMap API resource provides mechanisms to inject containers with configuration data while keeping containers agnostic of Kubernetes. A ConfigMap can be used to store fine-grained information like individual properties or coarse-grained information like entire config files or JSON blobs.

There are multiple ways to create a ConfigMap: from a directory upload, a file, or from literal values in command line as shown in the following example:
 

$ kubectl create configmap ckad-example-config --from-literal foo=bar

 
Learn more about ConfigMaps

Secrets

Secrets hold sensitive information, such as passwords, OAuth tokens, and SSH keys. Putting this information in a secret is safer and more flexible than putting it verbatim in a pod definition or a Docker image!

There are three types of secrets, explained by the --help flag:

$ kubectl create secret --help

Create a secret using specified subcommand.
Available Commands:
  docker-registry    Create a secret for use with a Docker registry
  generic            Create a secret from a local file, directory or literal value
  tls         	     Create a TLS secret

Example of creating a secret imperatively:

$ kubectl create secret generic my-secret \
--from-literal=username=ckad-user \
--from-literal=password=Char1!3-K!10-Alpha-D31ta

Learn more about Secrets

Mounting ConfigMaps/Secrets as volumes or environment variables

ConfigMaps and Secrets are mounted by Pods as either volumes or environment variables to be used by a container in a Pod.
 
ConfigMaps and Secrets can be used with a pod in two ways:

  • Files in a volume
  • Environment variables

 
Secrets can also be used by the kubelet when pulling images for a pod, called an imagePullSecret
 
The following Pod manifest mounts the ConfigMap ckad-example-config as a volume to the /etc/myapp directory in the container and uses a secret called “ckad-training-docker-token” as an imagePullSecret:
 

apiVersion: v1
kind: Pod
metadata:
  name: pod-config
spec:
  containers:
    - name: nginx
      image: nginx:latest
    imagePullSecrets:
    - name: ckad-training-docker-token
      volumeMounts:
      - name: config
        mountPath: /etc/myapp
  volumes:
    - name: config
      configMap:
        name: ckad-example-config

 
Learn more about mounting ConfigMaps
Learn more about mounting Secrets

Service Accounts

Service Accounts are users managed by the Kubernetes API that provide processes in a pod with an identity in the cluster. Service Accounts are bound to a set of credentials stored as secrets in the same namespace in the cluster. Every container in a pod within a namespace inherits credentials from their designated service account.
 
Service Accounts are entirely managed by the API, and are created by making API calls to the Kubernetes API server. kubectl automates the process of creating service accounts with the create subcommand. The example below shows an imperative command that creates a serviceAccount called ckadexample under the namespace called ckadtraining:
 

$ kubectl create namespace ckadtraining

 

$ kubectl create serviceaccount ckadexample --namespace ckadtraining

 
A service account has no permissions within the cluster by default. The service account must be bound to a role that defines its permissions using a rolebinding. The following example creates a role that allows our new service account to view pods within the ckadtraining namespace and a rolebinding that grants those permissions to the ckadexample SA:
 

$ kubectl create role ckadsarole \
--namespace ckadtraining \
--verb=get,list,watch \
--resource=pods

 

$ kubectl create rolebinding ckadsarolebinding \
--namespace ckadtraining \
--role=mysarole \
--serviceaccount=ckadtraining:ckadexample

 
Learn more about ServiceAccounts

Practice Drill

Create a pod that runs the nginx image and uses a service account called my-sa.

As an additional exercise, try creating a ConfigMap and/or Secret and using it in a Pod as a volume or environment variable; remember the 6-minute time constraint!

RX-M offers complete CKAD Boot Camps to make securing your CKAD certification manageable.

KTP-logo.svg
KCSP-logo.svg
cncf-member-silver.svg
lf-atp-logo.svg
apache-bronze-sponsor-logo.svg
devops-institute-partner-logo-150.png

Our team has been trusted to work alongside some of the world's leading companies

grey-client-logos-16-mar-2020.svg