Deployment Configuration
Volumes
a volume is a directory (possibly pre-populated) made available to containers in a Pod
a Kubernetes volume shares at least the Pod lifetime, not the container within
if you want your storage lifetime to be distinct from a Pod, use Persistent Volumes. These allow for volumes to be claimed by a Pod using PersistentVolumeClaims.
a volume can persist longer than a pod, and can be accessed by multiple pods using PersistentVolumeClaims. This allows for state persistency
a volume can be made available to multiple pods, with each given an access mode to write
we can pass encoded data to a pod using Secrets and non-encoded data using a ConfigMap - we can pass things like SSH keys, passwords etc...
there is no concurrency checking, which means data corruption is probable unless outside locking takes place
-
examples of volume types:
- rbd
- NFS
- gcePersistentDisk
There are three access modes for volumes:
- RWO(ReadWriteOnce) - allows read-write by a single node
- ROX(ReadOnlyMany) - allow read-only by multiple nodes
- RWX(ReadWriteMany) - allows read-write by multiple nodes
When a volume is requested, the local kubelet uses the kubelet_pods.go script to:
- map raw devices
- determine and make mount point for container
- create symbolic link on the host filesystem to associate the storage with the container
If no particular StorageClass was requested, only access_mode and size are used as params to create a volume.
Volume types
There are many different types of volumes such as GCEpersistentDisk or awsElasticBlockStore (GCE and EBS respectively)
An emptyDir volume is first created when a Pod is assigned to a Node, and exists as long as that Pod is running on that node. As the name says, it is initially empty. Containers in the Pod can all read and write the same files in the emptyDir volume, though that volume can be mounted at the same or different paths in each Container. When a Pod is removed from a node for any reason, the data in the emptyDir is deleted forever.
A hostPath volume mounts a file or directory from the host node’s filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.
Secrets
Secrets in kubernetes are not encrypted by default - only base64 encoded.
Config Maps
Data in ConfigMaps in kubernetes is not encoded or encrypted and contains key-value pairs or plain configuration files in any format.
Here are a few uses of ConfigMaps:
- Pod env vars from single or multiple ConfigMaps
- Use ConfigMap values in Pod commands
- Populate Volume from ConfigMap
- Add ConfigMap data to specific path in Volume
- Set file names and access mode in Volume from ConfigMap data
- Can be used by system components and controllers.
Creating ConfigMaps
ConfigMaps can be created in one of the three following ways:
kubectl create configmap myconfigmap \
--from-literal=city=London \
--from-file=./myconfigmapfile.txt \
--from-file=./myconfigmapdirectory/
which results in the following ConfigMap:
k get configmap myconfigmap -o yaml
apiVersion: v1
data:
city: London
kind: ConfigMap
metadata:
creationTimestamp: "2020-01-12T11:22:43Z"
name: myconfigmap
namespace: default
...
Scaling and Rolling Update
To scale a deployment we can use
kubectl scale deploy/mydeployment --replicas=4
and then to downscale
kubectl scale deploy/mydeployment --replicas=1
Deployment rollbacks
Let's say we want to update a container's image using the following command
kubectl set image deployment/test nginx=nginx:0.9 --record
Let's say we now want to update to an even newer version of nginx using the following command
kubectl set image deployment/test nginx=nginx:66.6 --record
If you now run kubectl get pods
you will see that the pod is stuck in ImagePullBackoff
state so we want to immediately rollback the changes to a previously working version. We can do this using the following command
kubectl rollout undo deployment/test
To view a history of all events we can run
kubectl rollout history deployment/test
which shows the following output:
deployment.apps/test
REVISION CHANGE-CAUSE
1 kubectl set image deploy/test test=nginx --record=true
4 kubectl set image deployments/test nginx=nginx:0.8 --record=true
5 kubectl set image deployments/test nginx=nginx:0.9 --record=true
6 kubectl set image deployments/test nginx=nginx:0.66 --record=true
7 kubectl set image deployments/test nginx=nginx:66.66 --record=true
8 kubectl set image deployments/test nginx=nginx:66.66 --record=true
Top comments (0)