Skip to main contentIBM Garage Cloud Native Bootcamp

Kubernetes Configuration

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

IKS

References

apiVersion: v1
kind: ConfigMap
metadata:
name: my-cm
data:
color: blue
location: naboo
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: myapp
image: busybox
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: myapp
image: busybox
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: myapp
image: busybox

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

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

IKS

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:
restartPolicy: Never
securityContext:
runAsUser: 2000
runAsGroup: 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:
restartPolicy: Never
securityContext:
runAsUser: 2001
runAsGroup: 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

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>

Activities

TaskDescriptionLink
Try It Yourself
Pod CreationChallenge yourself to create a Pod YAML file to meet certain parameters.Pod Creation
Pod ConfigurationConfigure a pod to meet compute resource requirements.Pod Configuration