The Certified Kubernetes Administrator (CKA) is a certification created by the Cloud Native Computing Foundation (CNCF) with the purpose “to provide assurance that CKAs have the skills, knowledge, and competency to perform the responsibilities of Kubernetes administrators”. It’s a proctored, performance-based test which means there are several tasks that need to be done, from a command line, to solve multiple issues. Having recently passed the exam myself, a few tips and tricks could be helpful....

We’ve been operating a few Kubernetes clusters. Someone trips over, falls on a keyboard, and deletes several services. We need to (quickly!) get those back online. We have several options to get things back to how they were: we have everything in version control - pipelines or GitOps reconcilers will take care of it; restore ectd backup - all Kubernetes objects are stored on etcd. Periodically backing up the etcd cluster data can be a lifesaver under disaster scenarios; use specific Kubernetes backup tools - for example Velero....

The proliferation of the cloud and Kubernetes made it “easier” to provision new environments dynamically, democratizing the access to resources that can be used, for example, for testing. That comes with its own set of challenges; dynamically provisioning Roles and RoleBindings being some of them. If we think of a new “environment” as a namespace in Kubernetes, each of them will have its own Roles and RoleBindings and we would like for them to be managed dynamically....

There are several options when it comes to Continuous Delivery, powered by the GitOps toolkit, and Argo CD is one of the most popular. It describes itself as “a declarative, GitOps continuous delivery tool for Kubernetes.” Following the GitOps philosophy, Argo is/has: declarative since it uses Git as its source of truth where the entire desired state is described; automated because it can read state (described in YAML) and act upon it; auditable due to Git history; designed for Kubernetes from the ground up; out-of-the-box integrations so that the wheel doesn’t need to be reinvented; extensible allowing for particular use cases to be added....

In it’s website we can read that “Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.” That is, obviously, powered by the GitOps toolkit have it not been developed (and open-sourced) by Weaveworks. Following the GitOps philosophy, Flux is/has: declarative since it uses Git as its source of truth where the entire desired state is described; automated because it can read state (described in YAML) and act upon it; auditable due to Git history; designed for Kubernetes from the ground up; out-of-the-box integrations so that the wheel doesn’t need to be reinvented; extensible allowing for particular use cases to be added....