Container Configuration

Command and Argument

When you create a Pod, you can define a command and arguments for the containers that run in the Pod.

The command and arguments that you define in the configuration file override the default command and arguments provided by the container image

Dockerfile vs Kubernetes Dockerfile Entrypoint -> k8s command Dockerfile CMD -> k8s args

Ports

When you create a Pod, you can specify the port number the container exposes, as best practice is good to put a name, this way a service can specify targetport by name reference.

Environment Variable

When you create a Pod, you can set environment variables for the containers that run in the Pod. To set environment variables, include the env or envFrom field in the container configuration

A Pod can use environment variables to expose information about itself to Containers running in the Pod. Environment variables can expose Pod fields and Container fields

Resources

IKS & OpenShift

References

apiVersion: v1
kind: Pod
metadata:
  name: my-cmd-pod
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['echo']

apiVersion: v1
kind: Pod
metadata:
  name: my-arg-pod
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['echo']

apiVersion: v1
kind: Pod
metadata:
  name: my-port-pod
spec:
  containers:
  - name: myapp-container
    image: bitnami/nginx
    ports:

apiVersion: v1
kind: Pod
metadata:
  name: my-env-pod
spec:
  restartPolicy: Never
  containers:
  - name: c
    image: busybox

apiVersion: v1
kind: Pod
metadata:
  name: my-inter-pod
  labels:
    app: jedi
spec:
  restartPolicy: Never
  containers:

Resource Requirements

When you specify a Pod, you can optionally specify how much CPU and memory (RAM) each Container needs. When Containers have resource requests specified, the scheduler can make better decisions about which nodes to place Pods on.

CPU and memory are each a resource type. A resource type has a base unit. CPU is specified in units of cores, and memory is specified in units of bytes.

Resources

IKS & OpenShift

References

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    image: bitnami/nginx
    ports:

Namespaced defaults mem

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:

Namespaced defaults mem

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
  - default:
      cpu: 1
    defaultRequest:

ConfigMaps

ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable.

You can data from a ConfigMap in 3 different ways.

As a single environment variable specific to a single key
As a set of environment variables from all keys
As a set of files, each key represented by a file on mounted volume

Resources

OpenShift

Mapping Volumes

IKS

ConfigMaps

References

apiVersion: v1
kind: ConfigMap
metadata:
   name: my-cm
data:
   color: blue
   location: naboo

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: myapp
      image: busybox
      command: ["echo"]

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: myapp
      image: busybox
      command:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: myapp
      image: busybox
      command: ["/bin/sh", "-c", "env | sort"]

Secrets

Kubernetes secret objects let you store and manage 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 in a container image.

A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image; putting it in a Secret object allows for more control over how it is used, and reduces the risk of accidental exposure.

Resources

OpenShift

IKS

References

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
stringData:
  admin: administrator

apiVersion: v1
kind: Secret
metadata:
  name: mysecret-config
type: Opaque
stringData:
  config.yaml: |-
    apiUrl: "https://my.api.com/api/v1"
    username: token

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-app
    image: bitnami/nginx
    ports:

Create files needed for rest of example.

echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt

Creating Secret from files.

oc create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

Getting Secret

oc get secrets

Gets the Secret’s Description.

oc describe secrets/db-user-pass

Create files needed for rest of example.

echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt

Creates the Secret from the files

kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

Gets the Secret

kubectl get secrets

Gets the Secret’s Description.

kubectl describe secrets/db-user-pass

SecurityContexts

A security context defines privilege and access control settings for a Pod or Container.

To specify security settings for a Pod, include the securityContext field in the Pod specification. The securityContext field is a PodSecurityContext object. The security settings that you specify for a Pod apply to all Containers in the Pod.

Resources

OpenShift

Managing Security Contexts

IKS

Security Contexts

References

Setup minikube VM with users

minikube ssh

su -

echo "container-user-0:x:2000:2000:-:/home/container-user-0:/bin/bash" >> /etc/passwd
echo "container-user-1:x:2001:2001:-:/home/container-user-1:/bin/bash" >> /etc/passwd
echo "container-group-0:x:3000:" >>/etc/group
echo "container-group-1:x:3001:" >>/etc/group
mkdir -p /etc/message/
echo "Hello, World!" | sudo tee -a /etc/message/message.txt
chown 2000:3000 /etc/message/message.txt
chmod 640 /etc/message/message.txt

Using the this securityContext the container will be able to read the file /message/message.txt

apiVersion: v1
kind: Pod
metadata:
  name: my-securitycontext-pod
spec:
  securityContext:
    runAsUser: 2000
    runAsGroup: 3000
    fsGroup: 3000

Using the this securityContext the container should NOT be able to read the file /message/message.txt

apiVersion: v1
kind: Pod
metadata:
  name: my-securitycontext-pod
spec:
  securityContext:
    runAsUser: 2001
    runAsGroup: 3001
    fsGroup: 3001

Run to see the errors

Get Pod Logs

oc logs my-securitycontext-pod

Should return

cat: can't open '/message/message.txt': Permission denied

Get Pod Logs

kubectl logs my-securitycontext-pod

Should return

cat: can't open '/message/message.txt': Permission denied

Service Accounts

A service account provides an identity for processes that run in a Pod.

When you (a human) access the cluster (for example, using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually admin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).

User accounts are for humans. Service accounts are for processes, which run in pods.

User accounts are intended to be global. Names must be unique across all namespaces of a cluster, future user resource will not be namespaced. Service accounts are namespaced.

Resources

OpenShift

IKS

References

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: my-app
    image: bitnami/nginx

apiVersion: v1
kind: Secret
metadata:
  name: build-robot-secret
  annotations:
    kubernetes.io/service-account.name: my-service-account
type: kubernetes.io/service-account-token

Creating a ServiceAccount

oc create sa <service_account_name>

View ServiceAccount Details

oc describe sa <service_account_name>

Create a ServiceAccount

kubectl create sa <service_account_name>

View ServiceAccount Details

kubectl describe sa <service_account_name>

Activities

Task	Description	Link
*Try It Yourself*
Pod Creation	Challenge yourself to create a Pod YAML file to meet certain parameters.	Pod Creation
Pod Configuration	Configure a pod to meet compute resource requirements.	Pod Configuration

Edit this page on GitHub

Cloud-Native Foundation: Core Concepts

Cloud-Native Foundation: Multi-Container Pods