Passed Certified Kubernetes Administrator exam

About 2 weeks ago, I wrote about my LFCS experience and noticed that it was probably the hardest exam I’ve ever taken. Actually, the LFCS exam was my first step to the Certified Kubernetes Administrator exam. Why do you need LFCS or strong Linux skills before taking the CKA?

Well, the answer is quite simple – all exams are based on Linux, Kubernetes control plane and worker nodes are also Linux-based, so it’s quite logical to get/check/level up/confirm Linux skills, even though you work with Linux everyday. Anyway, let’s talk a bit about the CKA exam.

About the exam

  1. Exam duration is still 2 hours. I’ve been working with k8s for 3 years and 2 hours were quite enough to finish and even verify answers. I completed the exam in an hour and a half and had about 20 minutes to think on tasks I wasn’t sure about. In contrast, the LFCS exam didn’t provide me such opportunity and I spent whole 2 hours solving the tasks.
  2. 100% performance-based. The CKA exam requires all work to be done on the command-line. In my case the environment was based on Ubuntu 18.04 and Kubernetes 1.20. One of the main difference between CKA and LFCS – you are allowed to have ONE tab with kubernetes.io opened! It’s also logical. 2 hours would not be enough for writing yaml files without api/doc references. But again – you should be familiar with all objects of Kubernetes to pass the exam. Otherwise, the time limit will help you to fail (read docs at home, write yamls at the exam 🙂 )
  3. Online, Proctored, Certificate is valid for 3 years – Good news as I’m not ready to spend 300$ every year and don’t have so much time to take exams frequently.

Requirements and Preparation

  1. At least 1-2 years experience with Kubernetes in commercial projects (from setting up to troubleshooting/logging and monitoring)
  2. I ordered both LFCS and CKA exams a year ago and passed them on the last day of expiration. Both exams were purchased along with official online training courses, which I don’t recommend actually. They are 80% text-based + 20% of lab tasks available as PDF files. I don’t see significant differences between them and official docs (kubernetes.io/docs).
  3. Complete this FREE Linux Foundation course – Introduction to Kubernetes
  4. If you prefer books, I’d recommend Kubernetes in Action (2st edition going to be published later this year, you can start with the 1st ed.) and Core Kubernetes. I reviewed them both and they would be the great companions on your journey.
  5. I’m a fan of video courses and found that they make learning process more interactive and easier. Pluralsight is one the best choice for everything you need – Certified Kubernetes Administrator path
  6. One of the prefect preparation for the CKA is the Killer Shell – test environment containing 25 scenarios and their solutions. This exam simulator is much difficult than the real CKA exam – a great option for those who doesn’t have everyday practice with k8s. (I haven’t tried this service but heard great feedbacks on it)
  7. Because of 2 and as the last step, use the docs as the main source of truth, then do the tasks available at https://kubernetes.io/docs/tasks/ to check your knowledge.
  8. In summary, if you work with Kubernetes on a daily basis for years – you will pass the exam for sure (preparation would still be needed though). For others, complete the “from zero to hero” path and try your luck.

I wish you good luck and don’t ever give up. Cheers.

Kubernetes: ASP.NET Core HTTPS and mac verify failure

You are trying to configure HTTPS in ASP.NET Core to run on Kubernetes, successfully mounted secret data volumes and defined ASP.NET environment variables, however, the following error appears in the pod’s log:

error:23076071:PKCS12 routines:PKCS12_parse:mac verify failure
at Internal.Cryptography.Pal.OpenSslPkcs12Reader.Decrypt(SafePasswordHandle password)

The reason is quite simple – a wrong password. Check out the manifest examples below to understand the behavior.

<doesn’t work> Kubernetes deployment manifest:

env:
            - name: "Kestrel__Certificates__Default__Path"
              value: /var/secrets/cert #data volume must be used here
            - name: "ASPNETCORE_Kestrel__Certificates__Default__Password"
              value: /var/secrets/password #wrong!
        

<works> Kubernetes deployment manifest:

env:       
            - name: "Kestrel__Certificates__Default__Path"
              value: /var/secrets/cert #data volume must be used here
            - name: "ASPNETCORE_Kestrel__Certificates__Default__Password"
              valueFrom: #works!
                secretKeyRef:
                  name: backend-tls
                  key: password

Noticed the difference? Instead of using the data volume path to the secret key “password” (cat /var/secret/password outputs the password without any issues, by the way), you need to explicitly define the env value by referring to the secret’s key. In my case, “/var/secret/password” (text, not a secret itself!) was assigned to the variable’s value and it was unexpected.

In short, check if the password is correct and try to define the secret as an environment variable rather than using data volumes.