This is part 3 in a multi-part series on my CKAD learning experience. For the other parts in the series, please check out the following links:<\/p>\n\n\n\n
As I mentioned in the intro to this blog series, my study plan was to cover the topics in the official curriculum for the CKAD<\/a> one by one \u2013 and share my learnings with you. In this post we’ll walk through configuration and these 5 topics:<\/p>\n\n\n\n Let\u2019s cover each of those five topics:<\/p>\n\n\n\n ConfigMaps<\/a> are a mechanism within Kubernetes are a mechanism to pass configuration data to the containers in your pods. That data could be command-line arguments, environment variables, ports\u2026 By using ConfigMaps, you keep configuration data outside of your pod definitions. Within ConfigMaps, you define key-value pairs of configuration data. <\/p>\n\n\n\n You can create\nConfigMaps in a couple of ways:<\/p>\n\n\n\n We’ll start of by creating our configmap, adding that to our pod, and then look at the value.<\/p>\n\n\n\n We can then exec into our container to get the environmental variable:<\/p>\n\n\n\n Let’s now do the same, but with a configuration file rather than a literal:<\/p>\n\n\n\n Then exec into the container to get the environmental variable:<\/p>\n\n\n\n The output here is<\/p>\n\n\n\n Which is actually the content of the file, not the variable itself. <\/p>\n\n\n\n Meaning we couldn’t directly set the environmental variable, but we get the content of the file. If you want to get the actual values, you should import the configmap with the flag You then see the actual value, not the whole content of the file.<\/p>\n\n\n\n To see the difference between the You can see the real impact of Using You can also create configmaps directly as YAML files. An example below:<\/p>\n\n\n\n You can create this via:<\/p>\n\n\n\n We can reference this configmap in the following way:<\/p>\n\n\n\n The output should be<\/p>\n\n\n\n Configmaps are a way to store non-secret data in the kubernetes apiserver. There are multiple ways to create them. When using a file, you should be careful and distinguish between A securitycontext <\/a>describes the privileges and access control that a pod will use. Some settings here include (from the kubernetes docs):<\/p>\n\n\n\n This is actually a very important topic to dive\ninto. As we’re prepping for the exam, I don\u2019t want to dive too deep into the\ndetails of all the settings and the topics. Let’s have a look at some of the\nsettings.<\/p>\n\n\n\n We’ll start of with creating a simple pod, without a security context. <\/p>\n\n\n\n Let’s create this with the command Once in our container, let’s have a look at our current processes and user. You’ll see everything is running as root, and you’re logged as Let’s now change our pod definition, to include a user and group id:<\/p>\n\n\n\n Let’s now do the same: create the container, exec into it, and look at out processes and user. <\/p>\n\n\n\n Let’s have a look at what we did here, we defined at the pod level <\/strong>a securitycontext. This means all containers in our pod will run as a certain user. Let’s have a look at what happens when we combine both, a pod securitycontext and one specifically on our container:<\/p>\n\n\n\n We see an outcome as expected. We use the Application resource requirements<\/a> – and constraints – are critical within a kubernetes application definition. It provides information to the kubernetes system on how many resources should be ‘reserved’ for each container in the pods in a deployment – and it can set maxima as well. Additionally, it also allows you to set quota at namespace level; so a certain namespace cannot exceed a certain amount of resources. <\/p>\n\n\n\n There\nare four definitions for resource requirements:<\/p>\n\n\n\n The\nkubernetes scheduler will work with the requests and limits to schedule pods\nacross your cluster. The sum of the requests for containers in the pods running\non a node will never exceed the total available resources on that node. This\nmeans that on a 2 core machine, a maximum of 4 pods with a request of 500m will\nbe scheduled. <\/p>\n\n\n\n Please take into account that requests are reserved, and are not linked to the actual usage on your cluster. With incorrect requests, you could run a very underutilized cluster. <\/p>\n\n\n\n Let\u2019s start playing around a little with CPU requirements first:<\/p>\n\n\n\n What you see in the yaml above, is that we create a stress container. We limit it to 1CPU, with a reservation of 0.5CPU, while we’re running stress with 2CPUs. Let’s look at how much CPU is being used:<\/p>\n\n\n\n One thing I want you to notice here: when exceeding the limits, the pod kept running (i.e. wasn’t killed), and was just limited. This is different with memory usage, let’s have a look:<\/p>\n\n\n\n Let’s start with creating a pod that will try to get 150MB of memory, while being allowed 200MB. This should work, without any glitches:<\/p>\n\n\n\n We can create this and then watch the memory utilization:<\/p>\n\n\n\n And if we check a We can now edit the pod definition, and put a memory limit of 125Mi in place. This will create issues, and will cause kubernetes to kill and restart our pod.<\/p>\n\n\n\n We can create this pod, and we can quickly see that I’ll get killed and restarted:<\/p>\n\n\n\n As you can see, the container is killed due to exceeding it’s memory requirements. Notice how this is different from our earlier CPU scenario?<\/p>\n\n\n\n If\nyou’ve followed along with our Configmaps example earlier, you’ll notice a lot\nof similarities to secrets. In essence, secrets are configmaps that are base64\nobfuscated. There’s a couple of ways to create secrets, with the clue here\nbeing who does the base64 encoding:<\/p>\n\n\n\n Afterwards you can consume secrets in your pods, we’ll check that after we created a few. Let’s have a look at all three mechanisms:<\/p>\n\n\n\n Let’s quickly create a file with the value of a secret:<\/p>\n\n\n\n We can now create a secret referencing that file:<\/p>\n\n\n\n We can then look at the secret, which will look like this:<\/p>\n\n\n\n As you can see, the text itself is obfuscated. We can decode this using base64:<\/p>\n\n\n\n We can do the same using a literal-value, using the following kubectl:<\/p>\n\n\n\n We can then do the same as before, get the secret and decode the value:<\/p>\n\n\n\n Last way to create a secret is to create it via a yaml file. This yaml file expects your secret to be base64 encoded already, so let’s first base64 encode a string and create a secret:<\/p>\n\n\n\n We can then create this secret, and do the same as before, trying to decode it:<\/p>\n\n\n\n Let’s now have a look on how we can use these secrets in our pods:<\/p>\n\n\n\n Let’s have a look at how we can use the three secrets we created:<\/p>\n\n\n\n We’ll consume all three secrets in a single pod. We\u2019ll consume the file secret twice, once as an environmental variable and once as a volume.<\/p>\n\n\n\n We can then create our pod, exec into it, and have a look at the environment variables that are set and read our file. <\/p>\n\n\n\n A service account<\/a> provides an identity for processes that run in a Pod. This allows processes in a pod to communicate to the api-server. Each pod by default gets assigned the default<\/strong> service account.<\/p>\n\n\n\nConfigmaps<\/h2>\n\n\n\n
From a literal<\/h3>\n\n\n\n
kubectl create configmap literal --from-literal=MYNAME=Nills<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: config-literal\nspec:\n containers:\n - name: basic\n image: nginx\n env:\n - name: MYNAMEFROMLITERAL\n valueFrom:\n configMapKeyRef:\n name: literal\n key: MYNAME<\/strong><\/code><\/pre>\n\n\n\nkubectl create -f simplepodconfigliteral.yaml\nkubectl exec -it config-literal \/bin\/bash\necho $MYNAMEFROMLITERAL #FROM WITHIN THE CONTAINER<\/code><\/pre>\n\n\n\nFrom a configuration file<\/h3>\n\n\n\n
echo 'MYNAME=John Smith' > name.config\n\nkubectl create configmap fromfile --from-file=name.config<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: config-file\nspec:\n containers:\n - name: basic\n image: nginx\n env:\n - name: MYNAMEFROMFILE\n valueFrom:\n configMapKeyRef:\n name: fromfile\n key: name.config<\/code><\/pre>\n\n\n\nkubectl apply -f simplepodconfigfile.yaml<\/code><\/pre>\n\n\n\nkubectl exec -it config-file \/bin\/bash\necho $MYNAMEFROMFILE<\/code><\/pre>\n\n\n\nMYNAME=JohnSmith<\/code><\/pre>\n\n\n\n --from-env-file<\/code>. <\/p>\n\n\n\nkubectl create configmap fromenvfile --from-env-file=name.config<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: env-file\nspec:\n containers:\n - name: basic\n image: nginx\n env:\n - name: MYNAMEFROMFILE\n valueFrom:\n configMapKeyRef:\n name: fromenvfile\n key: MYNAME<\/code><\/pre>\n\n\n\nkubectl apply -f simplepodenvfile.yaml\nkubectl exec -it env-file \/bin\/bash\necho MYNAMEFROMFILE<\/code><\/pre>\n\n\n\n--from-file<\/code> flag, and the --from-env-file<\/code> flag, you can describe <\/code>(and compare) both configmaps (if you created both with me) by doing the following describes:<\/p>\n\n\n\nkubectl describe configmap\/fromfile configmap\/fromenvfile<\/code><\/pre>\n\n\n\nName: fromfile\nNamespace: default\nLabels: --from-file<\/code> and --from-env-file<\/code> if you have multiple values to set. To test this out, just add another value to name.config<\/code>, and recreate the configmaps:<\/p>\n\n\n\necho 'SECONDNAME=Test' >> name.config<\/code><\/pre>\n\n\n\nkubectl delete configmap\/fromfile configmap\/fromenvfile\nkubectl create configmap fromfile --from-file=name.config\nkubectl create configmap fromenvfile --from-env-file=name.config\nkubectl describe configmap\/fromfile configmap\/fromenvfile<\/code><\/pre>\n\n\n\nName: fromfile\nNamespace: default\nLabels: --from-file <\/code>actually loads the file, and using --from-env-file<\/code> loads the actual values in the file. <\/p>\n\n\n\nFrom a YAML file<\/h3>\n\n\n\n
kind: ConfigMap \napiVersion: v1 \nmetadata:\n name: config-from-yaml\ndata:\n myname: this-is-yaml<\/code><\/pre>\n\n\n\nkubectl apply -f configmap.yaml<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: config-yaml\nspec:\n containers:\n - name: basic\n image: nginx\n env:\n - name: MYNAMEFROMYAML\n valueFrom:\n configMapKeyRef:\n name: config-from-yaml\n key: myname<\/code><\/pre>\n\n\n\nkubectl apply -f simplepodyaml.yaml\n\nkubectl exec -it config-yaml \/bin\/bash\necho $MYNAMEFROMYAML<\/code><\/pre>\n\n\n\nthis-is-yaml<\/code><\/pre>\n\n\n\nSummarizing configmaps<\/h3>\n\n\n\n
--from-file <\/code>and --from-env-file<\/code>.<\/p>\n\n\n\nUnderstand SecurityContexts<\/h2>\n\n\n\n
apiVersion: v1\nkind: Pod\nmetadata:\n name: simple-security\nspec:\n containers:\n - name: basic\n image: nginx<\/code><\/pre>\n\n\n\nkubectl create -f simple-security.yaml<\/code> – and then exec into our container with kubectl exec -it simple-security sh<\/code><\/p>\n\n\n\nroot<\/code>:<\/p>\n\n\n\n\/ # ps aux\nPID USER TIME COMMAND\n 1 root 0:00 sleep 3600\n 59 root 0:00 sh\n 64 root 0:00 ps aux\n\/ # id\nuid=0(root) gid=0(root) groups=10(wheel)\n\/ # exit<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: user-security\nspec:\n securityContext:\n runAsUser: 1000\n runAsGroup: 3000\n fsGroup: 2000\n containers:\n - name: basic\n image: busybox\n command:\n - sleep\n - \"3600\"<\/code><\/pre>\n\n\n\nkubectl create -f user-security.yaml\npod\/user-security created\nkubectl exec -it user-security sh\n\/ $ ps aux\nPID USER TIME COMMAND\n 1 1000 0:00 sleep 3600\n 6 1000 0:00 sh\n 11 1000 0:00 ps aux\n\/ $ id\nuid=1000 gid=3000 groups=2000<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: container-security\nspec:\n securityContext:\n runAsUser: 1000\n runAsGroup: 3000\n fsGroup: 2000\n containers:\n - name: basic\n image: busybox\n command:\n - sleep\n - \"3600\"\n securityContext:\n runAsUser: 666<\/code><\/pre>\n\n\n\nkubectl create -f container-security.yaml\npod\/container-security created\nkubectl exec -it container-security sh\n\/ $ ps aux\nPID USER TIME COMMAND\n 1 666 0:00 sleep 3600\n 6 666 0:00 sh\n 11 666 0:00 ps aux\n\/ $ id\nuid=666 gid=3000 groups=2000<\/code><\/pre>\n\n\n\ngroupid<\/code> and groups<\/code> of the pod definition, but the more finegrained container policy is applied. <\/p>\n\n\n\nDefine an application resource requirements<\/h2>\n\n\n\n
CPU settings<\/h2>\n\n\n\n
apiVersion: v1\nkind: Pod\nmetadata:\n name: cpu-demo\nspec:\n containers:\n - name: cpu-demo-ctr\n image: vish\/stress\n resources:\n limits:\n cpu: \"1\"\n requests:\n cpu: \"0.5\"\n args:\n - -cpus\n - \"2\"<\/code><\/pre>\n\n\n\nkubectl create -f cpu-requests.yaml\npod\/cpu-demo created\nkubectl top pods\nNAME CPU(cores) MEMORY(bytes)\ncpu-demo 990m 1Mi<\/code><\/pre>\n\n\n\nMemory settings<\/h2>\n\n\n\n
apiVersion: v1\nkind: Pod\nmetadata:\n name: memory-low\nspec:\n containers:\n - name: memory-demo-ctr\n image: polinux\/stress\n resources:\n limits:\n memory: \"200Mi\"\n requests:\n memory: \"100Mi\"\n command: [\"stress\"]\n args: [\"--vm\", \"1\", \"--vm-bytes\", \"150M\", \"--vm-hang\", \"1\"]<\/code><\/pre>\n\n\n\nkubectl create -f memory-low.yaml\nkubectl top pods\nNAME CPU(cores) MEMORY(bytes)\nmemory-low 40m 151Mi<\/code><\/pre>\n\n\n\nkubectl get pods<\/code>, we’ll see zero restarts (as expected):<\/p>\n\n\n\nNAME READY STATUS RESTARTS AGE\nmemory-low 1\/1 Running 0 3m56s<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: memory-high\nspec:\n containers:\n - name: memory-demo-ctr\n image: polinux\/stress\n resources:\n limits:\n memory: \"125Mi\"\n requests:\n memory: \"100Mi\"\n command: [\"stress\"]\n args: [\"--vm\", \"1\", \"--vm-bytes\", \"150M\", \"--vm-hang\", \"1\"]<\/code><\/pre>\n\n\n\nkubectl create -f memory-high.yaml\nkubectl get pods --watch\n\nNAME READY STATUS RESTARTS AGE\nmemory-high 0\/1 OOMKilled 0 6s\nmemory-low 1\/1 Running 0 6m\nmemory-high 0\/1 OOMKilled 1 7s\nmemory-high 0\/1 CrashLoopBackOff 1 8s\nmemory-high 0\/1 OOMKilled 2 21s<\/code><\/pre>\n\n\n\nCreate and consume secrets<\/h2>\n\n\n\n
Using kubectl, referencing a file:<\/h3>\n\n\n\n
echo 'love' >secretingredient.txt<\/code><\/pre>\n\n\n\nkubectl create secret generic recipe --from-file=.\/secretingredient.txt <\/code><\/pre>\n\n\n\nkubectl get secret recipe -o yaml\napiVersion: v1\ndata:\n secretingredient.txt: bG92ZQo=\nkind: Secret\nmetadata:\n creationTimestamp: \"2019-07-17T04:17:49Z\"\n name: recipe\n namespace: default\n resourceVersion: \"3404565\"\n selfLink: \/api\/v1\/namespaces\/default\/secrets\/recipe\n uid: d63c536a-a849-11e9-aedb-0aee3919cf84\ntype: Opaque<\/code><\/pre>\n\n\n\necho \"bG92ZQo=\" | base64 -d -\nlove<\/code><\/pre>\n\n\n\nUsing kubectl, using literal values<\/h3>\n\n\n\n
kubectl create secret generic recipe --from-literal=mysecret=ilovekubernetes<\/code><\/pre>\n\n\n\nkubectl get secret literalsecret -o yaml\napiVersion: v1\ndata:\n mysecret: aWxvdmVrdWJlcm5ldGVz\nkind: Secret\nmetadata:\n creationTimestamp: \"2019-07-17T04:22:12Z\"\n name: literalsecret\n namespace: default\n resourceVersion: \"3404979\"\n selfLink: \/api\/v1\/namespaces\/default\/secrets\/literalsecret\n uid: 731c8496-a84a-11e9-aedb-0aee3919cf84\ntype: Opaque\n\necho \"aWxvdmVrdWJlcm5ldGVz\" | base64 -d -\nIlovekubernetes<\/code><\/pre>\n\n\n\nUsing a YAML file<\/h3>\n\n\n\n
echo \"heavymetal\" | base64 -\naGVhdnltZXRhbAo=<\/code><\/pre>\n\n\n\napiVersion: v1\nkind: Secret\nmetadata:\n name: music\ntype: Opaque\ndata:\n myfavorite: aGVhdnltZXRhbAo=<\/code><\/pre>\n\n\n\nkubectl create -f secret.yaml\nsecret\/music created\nkubectl get secret music -o yaml\napiVersion: v1\ndata:\n myfavorite: aGVhdnltZXRhbAo=\nkind: Secret\nmetadata:\n creationTimestamp: \"2019-07-17T04:26:20Z\"\n name: music\n namespace: default\n resourceVersion: \"3405365\"\n selfLink: \/api\/v1\/namespaces\/default\/secrets\/music\n uid: 070d7b14-a84b-11e9-aedb-0aee3919cf84\ntype: Opaque\n\necho \"aGVhdnltZXRhbAo=\" | base64 -d -\nheavymetal<\/code><\/pre>\n\n\n\nUsing secrets<\/h3>\n\n\n\n
apiVersion: v1\nkind: Pod\nmetadata:\n name: secretsconsumed\nspec:\n containers:\n - name: basic\n image: busybox\n command:\n - sleep\n - \"3600\"\n env:\n - name: FROMFILE\n valueFrom:\n secretKeyRef:\n name: recipe\n key: secretingredient.txt\n - name: FROMLITERAL\n valueFrom:\n secretKeyRef:\n name: literalsecret\n key: mysecret\n - name: FROMYAML\n valueFrom:\n secretKeyRef:\n name: music\n key: myfavorite\n volumeMounts:\n - name: secret-volume\n mountPath: \"\/tmp\/supersecret\"\n readOnly: true\n volumes:\n - name: secret-volume\n secret:\n secretName: recipe<\/code><\/pre>\n\n\n\nkubectl create -f secretsconsumed.yaml\nkubectl exec -it secretsconsumed sh\n\/ # echo $FROMFILE\nlove\n\/ # echo $FROMLITERAL\nilovekubernetes\n\/ # echo $FROMYAML\nheavymetal\n\/ # cat \/tmp\/supersecret\/secretingredient.txt\nlove<\/code><\/pre>\n\n\n\nUnderstand ServiceAccounts<\/h2>\n\n\n\n