2

Overview of CNCF and Kubernetes Certifications

In this chapter, you’ll learn about Cloud Native Computing Foundation (CNCF) and its parent organization – the Linux Foundation. We will learn what is behind those foundations, how they appeared, and which projects are curated in their ecosystems. We will also talk about the CNCF community, governance, cloud roles, and the Kubernetes certification path.

While this is one of the least technical chapters of this book, the content you’ll learn about makes up about half of the Cloud Native Architecture domain topics from the KCNA certification, so make sure that you answer all the recap questions at the end of this chapter.

In this chapter, we will cover the following topics:

• OSS and open standards
• Linux and CNCF
• CNCF community and governance
• Cloud roles and personas
• Kubernetes certification path

Let’s get to it!

OSS and open standards

If you have ever worked in any IT position, there is a high chance that you’ve come across the term open source software (OSS), know what it means, and very likely already used some.

What is OSS?

OSS is when the source code of the software is publicly accessible and anyone can study, modify, and distribute it for any purpose.

Software cannot be considered open source simply because it can easily be found on the internet or can be downloaded from the darknet. Software is open source when it is released under one of the open source licenses, such as Apache 2.0 or GNU General Public License v3. Those licenses grant users the right to make modifications to the source code or even use it for commercial purposes. That’s right – you can use OSS to build new software and sell it without paying any license fees to anyone. Alternatively, you can modify existing OSS, add new features, and sell it or offer related support services.

While the history of OSS goes back to the early days of computing, it was at the beginning of the 90s when one of the most successful OSS was created. Yes, you’ve guessed it – we are talking about Linux.

The Linux kernel, which was started in 1991 by Linus Torvalds, is one of the most prominent examples of open source. For three decades, the project has attracted volunteer and enthusiast programmers willing to contribute for no compensation at all. At the time of writing, more than 15,000 people have contributed their time, skills, and effort to create a core operating system that powers 100% of the world’s supercomputers and about 95% of the world’s servers.

There are plenty of successful open source projects – Kubernetes, OpenStack, Terraform, Ansible, Prometheus, and Django are all open source. Even companies with huge engineering resources such as Google realize the power of open source communities and how much the open source ecosystem can boost a project. This is what happened with Kubernetes.

Kubernetes has attracted many passionate engineers since the early days and became the first project incubated at CNCF. But before we move on and learn more about CNCF, let’s touch on another important topic – open standards.

Open standards

In 2015, along with the establishment of CNCF, another important event occurred – the Open Container Initiative (OCI) was started.

OCI

OCI is an open governance structure whose purpose is to define open industry standards around container formats and runtimes.

OCI has a technical community within which industry participants may contribute to building container specifications that are vendor-neutral, portable, and open.

It also provides reference implementations and tools that deliver on the promise of containers for application portability. Those standards allow us to avoid vendor lock-ins (when a customer is forced to continue using a product or service because it is hard to switch to another vendor) and help ensure that different projects integrate and work well together. For example, as we learned in the previous chapter, container runtimes are not part of Kubernetes, so we need to make sure that different container runtimes and Kubernetes are fully compatible.

At the time of writing, OCI provides three important specifications for the container ecosystem:

• Image specification (image-spec) defines how to build and package an application into an OCI-compliant container image
• Runtime specification (runtime-spec) defines the container life cycle and execution environment
• Distribution specification (distribution-spec) defines the protocol to facilitate and standardize the distribution of container images using so-called registries

So, why are the OCI standards important?

Let’s look at a simple analogy regarding transportation. Imagine that each car manufacturer has a way of attaching the wheels to the axle. Wheel manufacturers would have a hard time creating rims for each make and model if they haven’t been standardized. But since everybody agreed to have certain wheel sizing parameters such as the width, diameter, number of bolt holes, and so on, it makes it possible for manufacturers to produce wheels that can fit any car model on the market. So, you can buy wheels based on your car’s specifications and be confident that they fit your car.

Similar to containers, we have image, runtime, and distribution standards that allow anyone to develop 100% compatible software. The establishment of OCI standards has allowed further expansion of the container ecosystem with the new software. Before the OCI, there was only one way to build container images – using Docker. Today, there are projects such as Kaniko, Podman, Buildah, and others.

You don’t need to know the exact differences at this point – just remember that OCI has marked an important point in the evolution of containers and the container ecosystem by providing open specifications. In the upcoming chapters, we will dive into Docker and some aspects of the OCI standards.

According to OCI, it does not seek to be a marketing organization or define a full stack or solution requirements – it strives to avoid standardizing technical areas undergoing innovation and debate (https://github.com/opencontainers/tob/blob/main/CHARTER.md). The organization that helped establish OCI and still plays a major role in its initiative is the Linux Foundation. Like with many open source projects, volunteers work in the field and would like to contribute their time to bring the technologies to the next level or bridge the gaps between existing projects.

We’ve already mentioned both CNCF and the Linux Foundation a few times here. Now, let’s get to know them better.

Linux and CNCF

The Linux Foundation is a non-profit organization that appeared in 2000 as a merger between Open-Source Development Labs and the Free Standards Group. Foundation was initially created to standardize, promote, and support the adoption of Linux, but it has significantly expanded its role in the open source community since then.

Today, the supporting members of the Linux Foundation include many of the Fortune500 companies such as Google, IBM, Samsung, Meta, and more. Foundation hosts many projects besides the Linux kernel. These include Automotive Grade Linux, Ceph (storage), XEN (hypervisor), Real-Time Linux, the OpenAPI Initiative (OAI), and many others. Don’t worry if you never heard of these projects before – you won’t be questioned about them during the exam.

In recent years, the Linux Foundation has expanded its programs through conferences, certifications, training, and new initiatives. One such initiative is the Cloud Native Computing Foundation (CNCF), which was launched in 2015.

CNCF

July 21, 2015, became a remarkable date for the whole open source community – Kubernetes 1.0 was released. Along with its release, Google, as the key driving force and contributor behind K8s, partnered with the Linux Foundation to form CNCF. Kubernetes became the seed technology and the first incubating project of the new foundation. CNCF’s mission was to advance container and cloud-native technologies and align the industry (https://www.cncf.io/about/who-we-are/):

“The Foundation’s mission is to make cloud-native computing ubiquitous.

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive the adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.”

We touched on the basics of cloud computing, containers, and microservices in Chapter 1, From Cloud to Cloud Native and Kubernetes, and will dive deeper into those and other topics mentioned in the CNCF mission statement in the following chapters.

Today, CNCF is supported by more than 450 members and plays a major role in the cloud-native ecosystem. It provides governance and supports open source projects to make them mature and ensure they’re in a production-ready state.

Speaking of maturity, there are three distinguished levels in CNCF:

• Sandbox: This is the entry point for early-stage projects that can add value to the CNCF mission. New projects might be aligned with existing projects if they complement them.
• Incubating: This is a project that is successfully used in production by the end users and has an ongoing flow of code commits and contributions, along with documentation, specifications, and a versioning scheme.
• Graduated: This is a project that has contributors from multiple organizations, maintains Core Infrastructure Initiative best practices, and has passed an independent third-party security audit. The project should also define governance and committer processes, as well prove to be in use by real users.

Every project hosted by CNCF has an associated maturity level. Projects increase their maturity levels by demonstrating that they received end user adoption, a healthy rate of code changes, and committers from different organizations.

In addition, all CNCF projects must adhere to the IP Policy and adopt the Code of Conduct. The Code of Conduct defines what behavior is acceptable and what is not to create a positive and emphatical collaborative environment. On the other hand, the IP Policy is concerned with intellectual property and determines which open source license shall be applied (typically, this is Apache 2.0 for the source code and Creative Commons Attribution 4.0 International for documentation and images).

CNCF community and governance

As open source projects such as Kubernetes gain momentum, they attract more contributors, which is always a good sign. However, larger communities may get out of control and quickly become a mess without adequate governance. While CNCF does not require its hosted projects to follow any specific governance model, for a project to graduate, an explicit governance and committer process must be defined. CNCF follows the principle of Minimal Viable Governance, which means the projects are self-governing and the CNCF bodies will only step in if asked for help or if things are going wrong.

Speaking about its structure, CNCF has three main bodies:

• Governing Board (GB): Takes care of marketing, budget, and other business decisions for CNCF
• Technical Oversight Committee (TOC): Responsible for defining and maintaining the technical vision, approving new projects, and aligning existing ones based on feedback
• End User Community (EUC): Provides feedback from end users and organizations to improve the overall experience in the cloud-native ecosystem

TOC also determines if a project has reached another level of maturity. Projects can remain in an incubating stage indefinitely, but they are normally expected to graduate within 2 years.

As you already know, Kubernetes was the first project to be incubated in CNCF and the first to reach Graduated status in 2018. That’s right – Kubernetes skipped the sandbox stage as it was first released at the same time CNCF was established. Since its inception, more than 10 other projects have graduated and about 100 projects are currently in the incubating or sandbox stage. In the next section, we’ll explore the roles and personas that are common in cloud and cloud-native.

Cloud roles and personas

Cloud-native is not only about technologies and architectures, but also about people and efficient collaboration in working environments. Therefore, it is common to have certain positions and roles in organizations working with cloud infrastructures and the cloud-native ecosystem. It is also a KCNA exam requirement to understand which roles we are talking about and which responsibilities they assume.

The following roles can be encountered in modern organizations that are adopting the cloud and cloud-native:

• Cloud Architect or Cloud Solutions Architect
• DevOps Engineer
• DevSecOps Engineer
• FinOps Engineer
• Site Reliability Engineer (SRE)
• Cloud Engineer
• Data Engineer
• Full Stack Developer

This list is not exhaustive, and you may sometimes see variations of these roles, but this should give you a general idea. Now, let’s make the differences between those roles and responsibilities clear:

• Cloud (Solutions) Architect: It comes as no surprise that an architect is responsible for designing the architecture of the cloud infrastructure and cloud-native applications. It must be highly resilient, observable, scalable, and have a high degree of automation.

Cloud Architects are also often responsible for cloud strategy and selecting cloud providers (public, private, or hybrid) and suitable services (IaaS/PaaS/SaaS/serverless). Architect roles require broad knowledge from many technical and non-technical domains. For example, they must know the difference between capital expenditure or upfront costs (CAPEX) and operational expenditures or simply speaking running costs (OPEX). Traditional data centers are an example of high CAPEX, while the public cloud is an example of zero or almost zero CAPEX, with costs mostly being operational (OPEX).

• DevOps Engineer: Dev stands for development, while Ops stands for operations. A DevOps Engineer is somebody who can do both by bridging the gaps between developers and operationalists. Typically, a DevOps Engineer is somebody who has had previous experience as both a software developer and a system administrator or as an infrastructure engineer. This knowledge allows them to effectively automate infrastructure in the cloud and a whole application life cycle, including development, testing, and release. DevOps Engineers often need to know at least one programming language (for instance Python, Ruby, or Golang), as well as several tools for automation (such as Terraform, Ansible, Puppet, and so on) and continuous integration and deployment/delivery (CI/CD) systems. Nowadays, you’ll also often see Kubernetes experience as one of the requirements for DevOps roles. DevOps, as a culture, emphasizes learning over blame and promotes shared responsibility and strong cross-team collaboration, along with continuous feedback loops.
• DevSecOps Engineer: This is very much like a DevOps Engineer, but with an extra focus on security. With DevSecOps, security is introduced at an early stage in application and infrastructure life cycles and requires tight collaboration with the security team.
• FinOps Engineer: Fin stands for financial, while Ops stands for operations. The FinOps engineer enables teams to track their budgets, provide transparency, and perform cost optimization in the cloud. This role requires a deep understanding of various pricing models and services in the cloud to find optimal and cost-efficient solutions.
• Site Reliability Engineer (SRE): The responsibilities of the SRE include maintaining and optimizing cloud infrastructures and applications. SRE is, in a way, similar to DevOps but focuses more on the operational part and especially on meeting application availability requirements or objectives defined in service-level agreements (SLAs) or service-level objectives (SLOs). SLA regulates the level of commitment between the service provider and clients regarding quality, availability, and responsibilities. SLOs are specific measurable characteristics of the SLA, such as availability or response time. SREs often participate in on-call rotation duties (that is, they are ready to react in case of incidents).
• Cloud Engineer: This is another role that’s similar to DevOps but focuses on the cloud specifics or service offerings of a cloud provider. Typically, the DevOps Engineer role requires a broader skill set, whereas a Cloud Engineer needs deeper knowledge about particular public cloud services.
• Data Engineer: In this role, an engineer must deal with data protection, data storage, performance and availability requirements, and various tools for data classification, retention, and analysis. As enterprises accumulate more and more data, they need to make use of it. Therefore, Data Engineers are more in demand these days.
• Full Stack Developer: This is a broad role in which a developer needs to be able to take care of both the frontend, for example, the user interface (UI) and backend parts of an application. The backend is a generic term that describes software implementation that’s not visible or accessible by end users. Sometimes, Full Stack developers can bring in some basic experience with cloud infrastructure and even DevOps tools.

While all these roles and personas are in extremely high demand all over the world, it may not be easy to get an offer for one of those if you are coming from a completely different background or if you’ve just graduated university or college and have no relevant working experience. Accomplished certifications always make your profile stand out and give you higher chances of getting an interview in one of the desired roles. You’ll find a few pieces of career advice at the end of this book, but for now, let’s see which Kubernetes certifications are offered by CNCF and what the certification path looks like.

Kubernetes certification path

At the time of writing, CNCF offers four Kubernetes certification exams:

• Kubernetes and Cloud Native Associate (KCNA)
• Certified Kubernetes Application Developer (CKAD)
• Certified Kubernetes Administrator (CKA)
• Certified Kubernetes Security Specialist (CKS)

CKA was the first exam to be launched in 2017 and was valid for 2 years, but later, the validity period was extended to 3 years. CKAD and KCNA also have a 3-year validity period; only the CKS exam is valid for 2 years after passing.

Out of all of the exams, CKS is the hardest and requires a candidate to hold a valid, non-expired CKA certification to demonstrate that they already possess sufficient K8s expertise. This means that while you can purchase CKS at any time, you won’t be able to take it unless you first pass CKA. All the other exams can be attempted in any order; however, the recommended path is shown in the following diagram:

Figure 2.1 – CNCF Kubernetes certification path

KCNA is the easiest exam on the list and the only one that is hands-off – that is, it contains multiple-choice questions. The other certifications are all hands-on and require you to complete activities on multiple K8s clusters in a terminal.

But don’t get your hopes up for a trivial KCNA exam. In fact, among entry-level certifications in the cloud field, it is a comparably hard certification. Even if you’ve worked in a relevant field for a few years, you are unlikely to pass it without any Kubernetes experience and some preparation. Make sure that you always answer all the recap questions and complete the mockup exam provided at the end of this book before attempting a real exam.

The following is some important information regarding the KCNA exam:

• 60 multiple choice questions
• 90 minutes to complete the exam
• A score of 75% or above is needed to pass
• The exam is scored automatically in around 24 hours
• Can be taken online from anywhere (webcam and microphone required)
• One free retake is included in the price

The following domains are tested in the KCNA exam:

• Kubernetes Fundamentals (46%)
• Container Orchestration (22%)
• Cloud-Native Architecture (16%)
• Cloud-Native Observability (8%)
• Cloud-Native Application Delivery (8%)

As you can see, Kubernetes makes up a major part of the exam. Therefore, the biggest part of this book (Part 3, Learn Kubernetes Fundamentals) is dedicated to K8s. Apart from that, the KCNA candidate should be able to confirm their conceptual knowledge of cloud-native and its landscape, projects, and practices. This includes high-level definitions from the previous chapter which might be questioned in KCNA.

The other three exams focus on different aspects of working with Kubernetes. The CKAD exam tests application deployment and management aspects, whereas CKA is more about setting up and managing Kubernetes itself. Nevertheless, these exams test many common domains and if you’ve passed one of those two, with a bit of extra preparation, you’ll pass the other one as well. Finally, CKS focuses on security and requires significant experience working with Kubernetes.

Summary

In this chapter, we’ve learned about OSS and the importance of open standards in terms of OCI. OCI defines image, runtime, and distribution specifications that allow anyone to develop fully compatible container software. For instance, Kubernetes does not include its own container runtime; instead, it implements support for standardized runtime interfaces, allowing it to work with many container runtimes. Open, defined standards have paved the way for many new projects in the cloud-native ecosystem and CNCF.

Next, we covered the history behind CNCF and the Linux Foundation. CNCF was founded at the same time that the first version of Kubernetes was released and it became the first incubated project. CNCF distinguishes three levels of project maturity: Sandbox, Incubating, and Graduated.

CNCF has three major bodies: Governing Board (GB), Technical Oversight Committee (TOC), and End User Community (EUC). TOC makes decisions about the maturity of CNCF projects. One of the requirements for a project to reach graduation is that it must have governance and committer processes defined.

Cloud-native needs the right people to do the job and this is supported by a range of roles and personas you can find today in high demand on the market. We’ve looked at and compared the different roles to understand how the Cloud Architect’s responsibilities are different from those of a DevOps Engineer or a Full Stack developer.

Finally, we looked at the Kubernetes certification path and looked closer at the KCNA exam that you are preparing for. Make sure that you answer all the recap questions before moving on to the next chapter, where we will look at Docker and run containers.

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter’s material. You will find the answers in the Assessments section of the Appendix:

1. Which of the following is a valid project maturity state in CNCF (pick multiple)?
   1. Sandbox
   2. Released
   3. Graduated
   4. Incubating
2. Which organization was started to establish industry standards for containers?
   1. Open Container Foundation
   2. Cloud Native Container Initiative
   3. Cloud Native Container Foundation
   4. Open Container Initiative
3. Which of the following requirements must a CNCF project meet to reach the Graduated state (pick multiple)?
   1. Have project development and maintenance plan for the next 3-5 years
   2. Have real users and defined governance and committer processes
   3. Have contributors from multiple organizations
   4. Follow Core Infrastructure Initiative best practices
4. Which of the following CNCF bodies determines if a project has reached another maturity level?
   1. End User Community (EUC)
   2. Governing Board (GB)
   3. Technical Oversight Committee (TOC)
   4. Technical Overview Committee (TOC)
5. Which of the following specifications is provided by the OCI (pick multiple)?
   1. Image specification
   2. Runtime specification
   3. Execution specification
   4. Distribution specification
6. Which of the following is required for a CNCF project at any maturity stage (pick two)?
   1. Acceptance of the CNCF Code of Conduct
   2. Acceptance of the CNCF IP Policy
   3. Acceptance of the GNU GPL v.3 license
   4. Acceptance of the Linux Foundation as the project owner
7. Which of the following does DevOps culture emphasize (pick multiple)?
   1. Shared responsibility
   2. Learning instead of blame
   3. Strong cross-team collaboration
   4. Developers should follow the Operations team
8. Which of the following organizations was founded with a mission to advance container and cloud-native technologies and align the industry?
   1. Linux Foundation
   2. Open Container Initiative
   3. Cloud Native Container Foundation
   4. Cloud Native Computing Foundation
9. Which of the following is likely to be among the Cloud Architect’s responsibilities (pick two)?
   1. Selecting a cloud provider and suitable services
   2. Designing the cloud infrastructure architecture
   3. Deploying applications to production
   4. Maintaining applications in the cloud
10. What is the difference between DevOps and DevSecOps Engineers?
    1. DevOps only takes care of operations
    2. DevSecOps only takes care of security aspects
    3. DevSecOps is like DevOps, but with an extra focus on security
    4. DevSecOps must have security-related certifications
11. Which of the following describes SRE (pick two)?
    1. SRE needs to be present on-site with the cloud providers
    2. SRE does not participate in any operations
    3. SRE works on maintaining and optimizing infrastructure and apps
    4. SRE needs to ensure that the application’s SLA and SLO are met
12. How are Cloud Engineers different from DevOps Engineers (pick two)?
    1. DevOps Engineers know nothing about the cloud
    2. Cloud Engineers have a deeper knowledge of cloud services
    3. DevOps Engineers often have a broader skill set
    4. DevOps Engineers need to do on-call duty, while Cloud Engineers don’t
13. What are the benefits of having Full-Stack developers in a team?
    1. Full-Stack can tackle both frontend and backend work
    2. Full-Stack developers deploy applications to the cloud
    3. Full-Stack developers write code faster
    4. Full-Stack developers write cleaner code
14. Why is it important to have Open Standards (pick two)?
    1. They help us avoid vendor lock-in
    2. They allow different software to be compatible
    3. They ensure bug-free software
    4. They prevent earning profits with software
15. Which of the following technologies is a DevOps Engineer likely to work with (pick multiple)?
    1. Frontend technologies (for example, JavaScript, HTML, and CSS)
    2. Automation tools (for example, Terraform, Ansible, and Puppet)
    3. CI
    4. CD