Introduction to Certified Kubernetes Application Developer (CKAD)

0:11Hi, guys.

0:12My name is Trevor Sullivan, and welcome to this skill

0:15on the Certified Kubernetes Application Developer training

0:19course here at CBT Nuggets.

0:21Now, this is a followup training course

0:24to the Certified Kubernetes Administrator course

0:27that we released in March of 2022.

0:31So there's several different exams

0:33that I wanted to familiarize yourself

0:35with before we get too much into the weeds on CKD specifically.

0:41So if you head out to the Cloud Native Computing Foundation

0:44or see on CNCF's website, there are

0:47several different certifications that you can obtain

0:50on the Kubernetes platform.

0:52And there's three main ones that I wanted to call out.

0:55The first one is the Certified Kubernetes Administrator

0:58Certification.

0:59And this is really important for anybody

1:01who is going to be in a type of role

1:03where they are responsible for deploying

1:06or administering and maintaining a Kubernetes cluster.

1:10There's a lot of important concepts

1:11that are covered in CKA specifically

1:14that cover how to set up a cluster,

1:16how to set up a highly available cluster, and things like that.

1:19And not all of those concepts are necessarily

1:23important for you as a developer of applications

1:27that are simply going to be deployed onto a Kubernetes

1:31platform.

1:31So if you're not in a role where you are predominantly

1:34responsible for maintaining and monitoring and managing

1:38Kubernetes clusters, then CKA may not

1:41be the primary certification that you're looking for.

1:44The second certification that I wanted

1:46to draw your attention to is the one

1:47we're going to be talking about in this course, which

1:50is Certified Kubernetes Application Developer.

1:52And this one really hones in on a lot more topics

1:55that are centered around designing and deploying

1:59applications on top of the Kubernetes cluster.

2:02Now, that being said, there is certainly

2:05some foundational knowledge about Kubernetes

2:07that's covered in the Certified Kubernetes Administrator or CKA

2:11exam that might be relevant for you

2:14as a application developer who's deploying onto Kubernetes.

2:18However, if you are primarily looking

2:21for one out of these three primary exams

2:24to cover, then as an application developer,

2:27I would probably encourage you to stick with the Certified

2:29Kubernetes Application Developer Certification exam.

2:33The one other certification I wanted

2:35to call your call your attention to

2:37is the Certified Kubernetes Security Specialist.

2:40And this one, as the name implies,

2:43focuses a lot more on the security aspect of Kubernetes--

2:46things like how to harden a Kubernetes cluster to ensure

2:50that it is secured from any malicious attackers,

2:53that malicious attackers are not able to gain

2:56unauthorized access to your Kubernetes clusters,

2:59how to do things like minimize vulnerabilities

3:02in microservices.

3:03And this actually has a lot of overlap

3:05with application developers, because as an app developer,

3:08when you are looking at reducing vulnerabilities

3:11of container-based applications being deployed on Kubernetes,

3:14minimizing those vulnerabilities from the original design

3:17is actually going to be a component of your application

3:20architecture.

3:21So keep in mind that there is going

3:23to be some overlap between these different certification exams.

3:26But the CKAD specifically is focused

3:29on people who are developing applications and trying

3:32to build pipelines to automate the deployment from code

3:36all the way to production pods running on Kubernetes.

3:40So CKS is a lot more security-focused.

3:42It talks about things like monitoring and logging

3:45and runtime security for your container

3:47runtime that you're using within your cluster, like containerd

3:50or the Docker runtime, for example.

3:53But what we're going to be focusing on in this course

3:56here at CBT Nuggets is Certified Kubernetes Application

3:59Developer.

3:59So just keep these certification exams in the back of your mind.

4:02You've got CKA.

4:04You've got CKAD.

4:05And then you've got CKS for security focus.

4:08And so that's kind of the high-level lay of the land

4:10as far as examinations go around the Kubernetes platform

4:14from the CNCF.

4:16Now, one of the nice things about the CNCF

4:18is that because it is part of the Linux Foundation,

4:22they're pretty transparent about the work that they are doing.

4:25And they actually have a repository over here on GitHub

4:29called GitHub.com/cncf/curriculum.

4:33And this repository actually contains several different PDF

4:39documents that cover the kind of topics

4:43that you are going to see in Certified Kubernetes

4:46Administrator, Certified Kubernetes Security Specialist,

4:50as well as the Certified Kubernetes Application

4:52Developer.

4:53So they provide this in PDF format here.

4:56It's basically just a two or three page

4:58document here that covers the high-level topics

5:01that we're going to be covering in the CKAD course.

5:05So I wanted to start off by going over

5:08this information with you from the curriculum and just talk

5:11about how you can kind of prepare mentally

5:15for the rest of this course, as well as prepare for the exam

5:19itself.

5:20Now, one thing I wanted to note is

5:21that the cost for the CKAD exam is $375.

5:26And the CNCF does actually include

5:29one free retake for that.

5:31So if you head out to their website,

5:33you'll see in the fine print right down here,

5:36the cost is $375, but it also does include one free retake.

5:40So if you're taking this exam and you're not sure

5:42if you're going to pass it on the first occasion,

5:46then maybe it's worth just kind of taking it, just

5:48to get a feel for how the exam format is, so that you can

5:52get more comfortable with it.

5:54And then if you don't happen to pass it on the first iteration,

5:57you always do get that one free retake as well.

6:00So just keep that in mind from a cost perspective, that even

6:03if you do pay that $375 but you don't pass it the first time,

6:06you still have that second chance without paying

6:08an additional fee on top of that $375.

6:12Now, something else that differs from the CNCF exams compared

6:18to other certification exams that I've personally taken

6:21in the past on things like the Microsoft platform as well

6:25as a bunch of the Amazon Web Services certification exams is

6:30that the CNCF exams are very much scenario-driven versus

6:35Q&A-driven.

6:36And what do I mean by that?

6:38Well, scenario-driven exams often

6:39are going to test very specifically your knowledge

6:42on a platform by actually having you execute commands

6:46within a shell environment to show that you actually

6:50understand the different concepts

6:52of a particular platform-- in this case, Kubernetes,

6:54of course.

6:55And so with these scenario-driven exams,

6:58you want to have a lot more hands-on experience

7:00than simply conceptual knowledge about a platform,

7:04as with some other vendor certifications out there.

7:08With AWS certifications, you can do a whole bunch of book

7:11learning and not really spend a lot

7:13of hands-on time with the platform,

7:15and you might actually be able to pass certain certification

7:18exams within the AWS ecosystem.

7:21Now, with Kubernetes, that is quite a bit

7:24different, because if you are not

7:26familiar with things like the kubectl command line

7:29utility, if you are not familiar with cluster architecture

7:32in Kubernetes and how you've got master nodes and worker nodes,

7:36if you're not familiar with the different components

7:38of a Kubernetes cluster-- like your API server, your scheduler

7:42component, your controller manager component that

7:45runs on your master nodes, as well as the kubelet component,

7:49which is responsible for actually running

7:51the pods on your worker nodes within your cluster,

7:54as well as static pods on your master nodes as well.

7:58If you're not familiar with a lot of those core concepts

8:00about Kubernetes and you try to take

8:02one of these scenario-driven exams,

8:04then you're probably going to find

8:06that you run into some challenges pretty quickly.

8:09When I first took the Certified Kubernetes Administrator exam

8:12and I first took one of these kind of scenario-driven exams,

8:15it really kind of opened my eyes to how specific

8:19they are with the different questions that they're asking.

8:21They're not just giving you three or four

8:23different options.

8:24They're giving you an objective that you have to accomplish,

8:26and then you have to actually run the commands

8:29and edit different text files and config

8:31files in your Kubernetes cluster in order

8:33to satisfy the requirements of that learning objective

8:37on the exam.

8:38So keep in mind that this is very

8:39different from many other vendor certification exams out there.

8:43And so you'll want to be mentally prepared before you

8:45actually attempt to take the exam for the first time

8:48to know that these are going to be scenario-driven questions,

8:51and that you're going to have to be

8:53familiar with shell commands, especially kubectl,

8:55since that's our primary interface for managing

8:58Kubernetes.

8:59And just have that knowledge going into this exam.

9:02So make sure that you spend a lot of hands-on time

9:04with Kubernetes.

9:05Don't just watch these videos in this course

9:07and expect that you're going to be able to pass.

9:09You really want to spin up your own clusters.

9:12Just the practice of spinning up and destroying clusters

9:15themselves is actually a really good experience as well,

9:18because that kind of forces you to kind of get

9:19your cluster back up and running on different cloud vendors

9:23out there.

9:23And I would encourage you to try different distributions

9:26of Kubernetes as well.

9:26Don't just settle for picking one distribution of Kubernetes

9:30and letting that be it.

9:31Sometimes, I've found that using Amazon EKS makes more sense.

9:36Sometimes I've found that using DigitalOcean's managed

9:39Kubernetes service gives me a little bit more awareness

9:42about some other open source tools within the Kubernetes

9:44ecosystem.

9:46For example, they use an open source utility called Cilium

9:50on their clusters by default that EKS does not use.

9:54Also, EKS has things that are specific to it, like IAM

9:57integration with AWS Identity and Access Management.

10:00And that simply doesn't exist in the DigitalOcean ecosystem.

10:03It doesn't have the same concept of IAM roles like AWS does.

10:07So play around with some of the different distributions

10:09of Kubernetes out there, different managed cloud

10:11providers, like DigitalOcean, Linode, Microsoft Azure,

10:17AKS, EKS from Amazon Web Services,

10:20and maybe even Google's Kubernetes Engine GKE as well.

10:23And then if you're looking for other distributions

10:25of Kubernetes that you can run locally,

10:28you might want to look at a distribution like K3S.

10:32K3S was actually originally developed by Rancher Labs,

10:34and it's a really nice lightweight distribution

10:36to run Kubernetes locally on your own systems.

10:40So that's one option.

10:41You've also got Kubernetes in Docker or the kind project.

10:46And this is another project that will actually

10:48allow you to spin up a Kubernetes cluster

10:50inside of Docker itself.

10:52So you're basically running Kubernetes

10:53as an array of containers.

10:55So that's kind of a cool option that you have as well.

10:57And then one of the easiest ways to get your Kubernetes cluster

11:02up and running is actually just to install Docker desktop here

11:04as well.

11:05So Docker desktop actually includes its own distribution

11:08of Kubernetes.

11:09So that's yet another option that you

11:11have to run Kubernetes locally.

11:12So there's a bunch of different distributions out there.

11:15But I would encourage you to practice

11:16with different distributions.

11:18Don't just use Google Kubernetes Engine and think,

11:21OK, I know enough.

11:22Play around with K3S.

11:24Play around with the built-in Docker desktop distribution

11:27of Kubernetes as well.

11:29And that'll just give you more breadth of experience

11:31and understand some of the nuances between how

11:34different distributions of Kubernetes works.

11:36So that's just something I wanted to kind of point

11:38out as you are preparing for the CKAD exam.

11:43Now, CKAD, as the name implies, is really geared more

11:46towards application developers.

11:48So the primary topics that are going to be covered

11:51are things around how to build container images

11:54and deploy container images as Kubernetes pods out

11:57into your cluster.

11:58There's a lot less emphasis on things

12:01like networking and cluster deployment and cluster

12:05monitoring and that kind of stuff.

12:06However, you are still going to want

12:08to know how to debug applications that are running

12:10in Kubernetes clusters, because as an application

12:13developer, if something goes wrong with one

12:16of your application pods, then you're going to need to things

12:19like, how do I get logs from pods?

12:21How do I run shell commands in pods,

12:24if I need to, in order to do investigative work, to gather

12:28data, so that I can debug any kind of problems

12:30that might be occurring in my Kubernetes-based applications?

12:34There are also some Kubernetes security topics

12:37that are going to be covered as well in CKAD.

12:40And we'll talk about those in a little bit more depth

12:42here in the overview skill here.

12:44But these are going to be a little bit more

12:46centered around things like how do I authenticate

12:48to the Kubernetes API server?

12:52How do I use security contexts?

12:54How do I use secrets?

12:56How do I create config maps to configure my applications

12:59in a more agnostic fashion?

13:01And things like that.

13:02So the primary topics in CKAD are

13:05going to be geared towards application developers that

13:08are working with a DevOps team that's ultimately

13:11going to be deploying production-scale applications

13:14onto Kubernetes clusters.

13:16Anyways, we're going to drill into these next videos

13:19and cover some of the topics in a little bit more depth.

13:22We'll cover just at a high level what some of these learning

13:25objectives are for the CKAD exam,

13:28and make sure that as you continue your learning journey

13:31in preparation for the CKAD exam,

13:34that you'll understand what these high-level topics are.

13:37And then in our other skills within the CKAD course,

13:40we're going to drill much deeper and actually

13:42get hands-on time with some of these concepts in Kubernetes

13:46so that you can go into CKAD best prepared

13:49so that you can successfully pass that exam.

13:52I hope this has been informative for you,

13:54and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back.

0:13So one of the high-level learning objectives

0:15in the certified Kubernetes Application Developer

0:18Certification exam is around application design

0:22and build in Kubernetes.

0:24So this is going to cover a lot of the most important concepts

0:27around how to actually build container

0:30images in your Kubernetes cluster,

0:32and then deploy those container images out

0:35to your Kubernetes cluster.

0:37Now, some of the specific topics that

0:39are going to be covered under this learning objective

0:41are things like defining Dockerfiles.

0:44So you're going to want to know how to create a Dockerfile.

0:48You want to understand what different base images are

0:51out there in the ecosystem to build off of to inject

0:55your application code into.

0:57Now, if you head out to a popular registry known

1:00as the Docker Hub over at hub.docker.com,

1:04this is where the bulk of base images are going to come from.

1:08And there's lots of different base

1:09images out on Docker Hub, anywhere from Linux

1:13distribution based options, like Ubuntu Linux,

1:16or if you search for Alpine Linux,

1:18there's Alpine-based images out here as well.

1:20But there's also container images

1:22out here that allow you to base your applications off

1:24of specific runtimes.

1:26So if you're building, let's say,

1:27a Python-based application, then you

1:29might want to start with one of the official Python-based

1:33images and then simply inject your application code,

1:36install any necessary Python dependencies from Python

1:39Package Index into your container image,

1:42and then use that as your basis for building your own custom

1:45application images.

1:46Similarly, let's say maybe you're a JavaScript developer,

1:49and so you're using the Node.js runtime in order

1:53to execute your application.

1:54In that case, you might actually use

1:56one of the official node-based images,

1:59and then inject your application code install your dependencies

2:02from your package.json file, and then

2:05set your command or your entry point into that container,

2:07and then that would build out to your container image.

2:11So knowing some of the different options for base images

2:14out there, knowing how to construct a Dockerfile,

2:18also knowing how to use the Dockerfile reference

2:22is a really good piece of documentation

2:24that's going to be helpful as you are learning how

2:27to build container images, because the Dockerfile

2:29reference is going to give you the authoritative list

2:32of commands that are available to use inside

2:35of your Dockerfile.

2:36And these are going to allow you to do

2:38different things, like install dependencies,

2:40install packages inside of your container image.

2:43You're going to be able to copy files from your container

2:47context into your--

2:49or I should say your Docker context--

2:50into your container image before you actually package it up.

2:55You'll also be able to set things

2:56like your working directory as well, where

3:00your application resides so that you

3:02can write temporary files in there

3:04or read configuration files.

3:06You can set arguments for your Dockerfiles as well.

3:10So knowing how to use the Dockerfile reference

3:13documentation to really find the specific Dockerfile

3:16commands that are going to help you to construct your container

3:19image--

3:20this is going to be an excellent resource if you are--

3:23especially if you're new to container building,

3:25but also if you're an experienced container

3:27developer, but there is maybe some lesser known

3:29commands that you just don't use very often

3:32inside of your Dockerfiles.

3:33Then the Dockerfile reference documentation

3:35is going to be a great place to refer back to any time

3:38that you are using different Dockerfile commands inside

3:42of your Dockerfiles.

3:44So knowing how to build container images

3:46is going to be really important.

3:48Of course, you can get a lot of practice building container

3:50images locally on your dev system

3:53without even using Kubernetes.

3:55So if you just have Docker Desktop installed

3:57on your local dev system, you can call the Docker CLI tool.

4:02If I just fire up a shell here, I

4:03can run the Doctor CLI tool here on my Windows 11 dev system.

4:08And I can do a Docker build command here.

4:11And I don't necessarily have to be using Kubernetes

4:13at this point to simply know how to create Dockerfiles

4:17and how to build container images.

4:19However, once you get around to actually deploying containers

4:24as pods onto your Kubernetes cluster,

4:26that's where you're really going to want

4:28to have a deeper knowledge about how

4:30to push container images to alternative registries.

4:34So maybe you're using Amazon Elastic Container Registry,

4:38which is a managed service that allows you

4:39to host your container images.

4:41Or maybe you're going out to the Docker Hub

4:45and maybe you're hosting private container images, instead of

4:49just the public images that are available out here.

4:52And so you'll need to things like, how do I

4:54deploy private container images from the Docker Hub

4:57or some other private registry?

4:59Maybe you're using even a Red Hat's Quay.io.

5:02So this is another example of a container image

5:05registry, where you can store your container images,

5:08host them out there, simply storing them

5:11on a managed service.

5:12And then, when you actually deploy pods

5:14onto your Kubernetes cluster, you

5:15can configure those pods to actually download

5:18container images from a registry like Quay.io,

5:22or Amazon Elastic Container Registry,

5:24or the Docker Hub as private images,

5:27or a whole bunch of other container registries

5:29out there as well.

5:30A lot of the cloud vendors that offer

5:32managed Kubernetes services also have a managed container

5:36registry.

5:37So for example, DigitalOcean--

5:39if you head out to DigitalOcean and you

5:42search for just the registry, you'll

5:44see that they do have a managed registry service here as well.

5:48So you can pick which registry service

5:50it is that you want to use for your particular team.

5:53Even if you're using Amazon Elastic Kubernetes service

5:56or Microsoft Azure Kubernetes service to actually

6:00deploy and run your cluster, that doesn't necessarily

6:03mean that you have to use the same managed service for using

6:08your registry as well.

6:09So just keep that in mind, that you

6:10do have a choice for where to run your Kubernetes cluster,

6:13as well as where to run your registry.

6:16Another high-level learning objective

6:18that you're going to come across under application design

6:21and build in Kubernetes is how to deploy pods

6:25as Jobs and CronJobs.

6:27Now, oftentimes, when you are deploying pods

6:30onto your Kubernetes cluster, you'll

6:32use a construct like a deployment controller,

6:35and that will allow you to scale your application.

6:38And then you can typically use what's

6:39known as a service controller, which

6:41is-- you can think of it like a load balancer that allows you

6:44to load balance incoming network traffic to the different pods

6:47for your application.

6:49However, Kubernetes also has a construct

6:51known as Jobs and CronJobs.

6:54So if you need to run pods in the background,

6:56and they're basically just maybe queue processors

7:00or they're just doing some kind of background processing--

7:02think of things like maybe a video processing application

7:05that's basically just taking video files and running

7:07conversions--

7:08or maybe if you need to run batch processes-- maybe

7:11you've got a batch process that generates reports

7:14every night at 2:00 AM local time or something like that.

7:18So in those cases, you can actually

7:20use a construct known as a CronJob resource

7:23in your Kubernetes cluster, and that

7:25will allow you to automatically spin up a pod on a schedule

7:30so that you don't have to run a persistent background job

7:33and waste compute resources to run those pods,

7:37even if they're just sleeping.

7:39So instead of having a long-running job that

7:41just sleeps for hours on end and just wastes compute resources

7:46in your cluster, you can instead just tell Kubernetes

7:49that you want to run a pod on a Cron schedule.

7:52And a Cron schedule will allow you

7:54to define a time-based expression that determines

7:58at what times of day the Kubernetes scheduler will

8:01go ahead and spin up a pod and actually schedule it onto one

8:07of your cluster worker nodes.

8:08So using these constructs to run background

8:11jobs on your cluster, and not just APIs, or web front ends,

8:16or other services that end users are going

8:18to be hitting from outside the cluster,

8:20you can also run just internal jobs inside of your cluster

8:23as well using both the Job resource as well as

8:26CronJobs resources as well.

8:29Another important concept that you're

8:31going to want to cover in application design and build

8:34is how to use multi-container pod design patterns.

8:39Now, Kubernetes pods are going to allow you to spin up

8:43more than a single container.

8:45So a pod is basically one or more containers

8:49that are all going to get scheduled onto the same node.

8:53When the Kubernetes scheduler schedules a pod

8:56to run on a particular worker node in your cluster,

8:59it's going to look at all of the containers that

9:01are inside of that pod spec or that pod

9:03definition in your YAML manifest files,

9:07and it's going to schedule all of the containers

9:09for that pod on the same node so that they're running locally

9:14to each other.

9:15Now, some of the common design patterns

9:17that you're going to see for multi-container pods

9:20are things like logging agents.

9:23So when you have an application--

9:25let's say maybe a web application, or an API server,

9:29or maybe you even have a background job or maybe

9:32a CronJob that's running.

9:33And you logging information from that application.

9:38So maybe you're logging API requests to an API

9:41and writing those out to a file, or maybe every time

9:45that you have a background job pod that is processing videos,

9:49maybe it's running some kind of conversion process

9:51on videos with FFmpeg.

9:54It's going to spit out some log messages

9:56to indicate when it's finished processing a particular video

9:59file.

10:00And so what you can do is actually

10:02capture those logs that are coming from your applications

10:06by using what's known as a sidecar technique.

10:09So rather than just having a single pod

10:12or a single container inside of your pod,

10:15you can actually set up a secondary-- what's

10:17known as a sidecar container, which is basically

10:20just a second container definition

10:22inside of your multi-container pod

10:24that is going to be responsible solely for gathering logs

10:29from the primary container that's actually running

10:32your application inside of the pod,

10:34and then taking those logs and forwarding

10:36those logs over to some centralized logging service.

10:41So that's the sidecar design pattern,

10:43where you have some kind of logging agent

10:45that's running in a secondary container

10:47in your multi-container pod spec.

10:50And that logging agent can then take those logs,

10:53and then it can either perform conversions on those logs

10:56and do some kind of log processing

10:58and then send it to your centralized logging store,

11:02or it can just send it directly to that log store

11:04without doing any processing ahead of time.

11:07So one popular logging agent out there is known as Fluentd.

11:11That is a popular open-source utility

11:13that allows you to grab logs and then forward them

11:17to some kind of destination.

11:19There's also a smaller sister project to that known as Fluent

11:22Bit, or there's also another project from the Elastic

11:26Stack called the Elastic--

11:28or sorry-- called Logstash.

11:30And Logstash works alongside Elasticsearch.

11:34So let me type Elasticsearch, and then Logstash.

11:37And this Logstash is an open-source utility

11:41that, again, allows you to capture logs

11:43from a variety of sources, then perform some kind of conversion

11:46on those logs, and then send them

11:48to some kind of destination.

11:51So knowing how to do things like that sidecar design pattern

11:53are going to be important for application developers,

11:56since, for the purpose of separation of concerns,

12:00it's a good idea to have a separate container that's

12:02actually doing the logging, rather than building all

12:05of the logging logic directly into your application

12:08container, as that could bloat your application

12:10and just increase the complexity of debugging your application.

12:15Now, pods also supports something

12:17known as an init container.

12:19So when your pods are originally scheduled onto a worker node,

12:23you can actually create what's known as an init container,

12:27and that will initialize the pods state.

12:31And this is really useful if you need to pre-populate

12:34a application with some data.

12:36So maybe you're running something like a Redis cache

12:39instance, or maybe you're running a database server

12:41or something like that, and you need

12:43to load some data into that application.

12:47Well, what you can do is create this thing called

12:49an init container, and that could

12:51have some kind of data loading script that can read data

12:54from a source-- maybe a file or some other network resource--

12:58and then load that data into your primary application pod

13:02inside of your multi-container pod design pattern.

13:05And then that can pre-populate data into your application,

13:10into your stateful database, or key-value store

13:14or things like that, and then that

13:15will allow you to reduce the amount of automation work

13:19that you need to do after the fact

13:21in order to initialize the state of that pod.

13:25So it's important to things like sidecar containers

13:28and init containers in your multi-container pod design

13:32patterns.

13:33Something else you'll want to know as an application

13:35developer, when it comes to things

13:37like stateful applications-- especially

13:39things like databases or value stores,

13:42like [INAUDIBLE] or Redis cache, for instance--

13:45is how to utilize volumes.

13:48So in Kubernetes, you can actually

13:50separate your application logic from your storage

13:54by creating what's known as a persistent volume.

13:57And then you can create something known

13:59as a persistent volume claim.

14:01And you can actually bind a persistent volume

14:04to an application pod, and then any data

14:07that is mapped into the file system,

14:10into that persistent volume will actually

14:13live outside of the lifecycle of a pod.

14:17Now, this is especially important

14:18for stateful applications.

14:20So imagine that you're running MySQL inside of a pod.

14:26All right, so if you run MySQL inside of a pod

14:28and you are writing data into it and creating databases,

14:33and tables, and rows inside of tables,

14:36then all of this data that you create as part of this MySQL

14:40database instance is going to need

14:42to be persisted, even if, for some reason,

14:45that pod were ever to die.

14:47So if your worker nodes inside of your cluster

14:50randomly get destroyed, for example--

14:53let's say that maybe there's an operating system level

14:55corruption, or memory corruption,

14:57or something like that-- well, that pod could

14:59die that's running MySQL.

15:01But then the Kubernetes Engine is

15:04going to detect that your pod has died,

15:06and it will automatically recreate

15:08a new pod running MySQL.

15:10But you don't want to start with a bare bones MySQL instance.

15:13You actually want it to load your database

15:15that you previously had running with all

15:18of your data, your table definitions, and all

15:20of your rows inside of it.

15:22Or maybe same thing with a graph database, like Neo4j.

15:26Maybe you're running Neo4j inside of a Kubernetes pod

15:28as well, and you create lots of nodes and relationships

15:33between nodes.

15:34And if, for some reason, your pod that's running Neo4j

15:37were to die as a result of a worker node being affected,

15:41then, of course, you don't want to have to recreate all

15:44your nodes and relationships.

15:45You want to be able to restore that database from where

15:48it left off when the pod died, and simply pick up from there

15:52and continue running your Neo4j instance.

15:55And so this is where persistent volumes are very important,

15:58because that's what's going to allow

16:00you to write your database files into different locations

16:04onto the file system, and then write that

16:06into external storage that's outside of the cluster.

16:10However, you can attach that storage to the cluster

16:13so that you can utilize the data inside of it.

16:16So that's how persistent volumes work at a high level.

16:19And then something else that you can do

16:21is well as use ephemeral volumes.

16:23So if you need to share data between containers

16:26in a multi-container pod design, then

16:29ephemeral volumes that can actually

16:30allow you to share data on a particular system path

16:35so that more than one container within a pod

16:38is able to access that information.

16:39So that's going to be really helpful

16:41if you have an application that's logging information.

16:44Maybe you've got a web server, and that's logging it

16:47to /mydata/mylogs or something.

16:53And then maybe you've got two different containers

16:56that one of them is writing to that location on the file

17:00system and one is a logging agent

17:03that's actually reading data from this file system location.

17:06And that's going to be your logging agent that will then

17:09forward those logs over to a different location.

17:12So if you need to share storage between containers in a pod,

17:16then you'll want to know how ephemeral volumes work

17:18in Kubernetes as well.

17:20So that's pretty much it for the application design

17:23and build in Kubernetes learning objective for CKAD.

17:27I hope this has been informative for you,

17:28and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back.

0:13So one of the other high level topics

0:14that's going to be covered in the Certified Kubernetes

0:17Application Developer Certification exam

0:20is around application deployment.

0:22So whereas we covered some of the application design

0:26and build principles in the previous learning objective,

0:29the application deployment learning objective

0:31is centered around how to actually get

0:34applications deployed onto a Kubernetes cluster.

0:37So once you've got your application packaged up

0:39as a container image, you've got it pushed up to your container

0:42registry that you're using, could

0:44be an external registry or an internal registry,

0:47now how do you actually deploy production applications out

0:50to your Kubernetes cluster?

0:52So one of the most important topics

0:53here is going to be something known as the deployment

0:56controller.

0:57If you are deploying applications

0:59that need to be scalable out to your Kubernetes cluster,

1:02the deployment controller, along with the ReplicaSet

1:05that's a child resource of the deployment controller-- knowing

1:09how these constructs work in Kubernetes

1:11is going to be incredibly important

1:13because the deployment controller is going

1:15to enable you to perform a couple of different types

1:19of deployments.

1:20And that is going to be the blue-green and canary

1:24deployments here.

1:25So let's talk really quickly about what

1:27these deployments are.

1:28So what is a blue-green deployment for starters?

1:31Well, let's say that you've got an old version

1:34of an application and a new version of an application.

1:38And you want to basically get your new version

1:41of your application deployed side

1:43by side with the current or old production

1:46version of your application.

1:47I'm actually going to change old to current.

1:49So I've got my current version, and I've

1:51got my new version of this application.

1:53And I want to get all of my users

1:55over to this new version of my application.

1:58Well, the blue-green deployment model

2:00is basically where you spin up a second copy of your application

2:05side by side with the current version

2:08that's already running in production.

2:10So you've got all your--

2:11100% of your traffic that's all hitting this current version,

2:14you deploy a second instance of your application

2:17on your Kubernetes cluster, could be the same cluster,

2:21and you then have two versions of the application running side

2:25by side, your current version and your new version.

2:29And then in a blue-green deployment,

2:31this is where you would actually cut over your traffic

2:34from the current version of your application

2:37over to the new version of your application.

2:40The reason they call it blue-green

2:42is because you have two different copies

2:44of your application.

2:45One's blue, your original version.

2:47The other is green.

2:48That's your green field or new version of your application

2:51that you're trying to get your users onto.

2:54And then when you perform a cut over,

2:56that's when you're basically cutting over that network

2:58traffic and telling all of your users,

3:00OK, I know you've been going to this old version

3:02of the application, but now I'm going to redirect you.

3:04And I'm going to cut you over to this new version

3:07of the application.

3:09The nice thing about doing a blue-green deployment

3:11is that if anything were to go wrong

3:12with that green or new version of your application,

3:16then you can actually just cut your users back over

3:18to the original version, the current version, that you were

3:22running previously, or that blue version,

3:24and that is going to allow you to get back

3:27to a known, good working state.

3:29So by doing blue-green deployments,

3:30you've got two copies of your application

3:32running side by side.

3:33And then you can cut your users over to that new version.

3:36If you have any problems, you can roll back

3:38to the previous version with relative ease.

3:41And then if you want to, after you've

3:44upgraded your users to that new green version,

3:46you can go ahead and then just shut down

3:48the blue or current version of your application.

3:52And then you'll only be left with your new version.

3:55And then that new version, once all of your users

3:57are successfully cut over to it, that new version actually

4:01becomes the next current version.

4:03And so then the next time that you

4:04go through another iteration where you're

4:06going to release a new version of your application,

4:09that new green version that's now become the current version

4:12will then become the blue version

4:14and then you'll have another new version

4:16that replaces the green.

4:18And so you'll continuously go through that process

4:21and iterate and continuously be adding new versions

4:24of your application.

4:25Now, a canary deployment is very similar

4:28to a blue-green deployment.

4:30However, there is one key difference

4:32with the canary deployment versus a blue green deployment.

4:35So when people talk about blue-green deployments,

4:37they're typically talking about spinning up two environments

4:40and then cutting your traffic over

4:41to that new green environment.

4:44With a canary deployment, this is a slight variation

4:47where you still have a blue-green version running side

4:50by side.

4:50However, with a canary deployment,

4:52you take a small percentage of your traffic, so maybe

4:555% of your traffic you want to redirect

4:58to the new version of your application.

5:02And the reason that you do this in a canary deployment

5:04is to minimize the impact of redirecting all of your users

5:09directly to the new application version.

5:12Imagine that your old application version--

5:15or, sorry-- your new application version

5:17actually introduces a new bug.

5:19Or maybe there's some feature that's

5:21missing from that new version that

5:23was present in the original or current version

5:26of your application.

5:28Well, if that were to happen in a blue-green deployment

5:30scenario, and you cut your application

5:33over from the current version to the new version,

5:36then that's going to impact 100% of your users.

5:39And that could be really catastrophic for a business

5:41that is running mission-critical applications.

5:44With a canary deployment, you can mitigate that risk

5:48by redirecting a small percentage of your traffic

5:51into the new application version.

5:54So you still spin up both the current and the new version

5:57of your application, but instead of redirecting all the traffic,

6:00you just redirect some of it.

6:02Now, after you've redirected, let's say, maybe 5%,

6:05or maybe 3%, or whatever number it is that you choose--

6:09once you've redirected a portion of your network traffic

6:12over to this new version, you've monitored your logs,

6:16you've monitored your data storage mechanism--

6:18if you're using MySQL or NoSQL database or a graph database,

6:22you want to just check the integrity of your data.

6:25You want to look at your application metrics.

6:27Make sure that there's no unexpected resource

6:30hogs in the new version of your application.

6:32Once you've verified that everything

6:34is working great for that initial 3% of users,

6:37then you can increase it.

6:38So I'm going to take it, maybe, from 3%

6:40and maybe raise it to 15% or maybe 10%,

6:43just to be a little bit more cautious.

6:45So with canary deployments, you're

6:47basically progressively increasing, over time,

6:50the percentage of traffic that you

6:52are sending over to a new version of your application.

6:56Now, eventually, you'll hit 100% of all of your traffic.

7:01And so once 100% of all of your traffic

7:04has successfully been migrated to the new version

7:07of your application, you can then

7:09spin down the old version of your application.

7:12And then once you've done that, you

7:14can continue to iterate on that same process,

7:17spin up another new version of your application,

7:19and then spin down the old version of the application.

7:22And by using that canary rollout process,

7:24you're actually minimizing the risk

7:26of cutting all of your network traffic over.

7:29And the deployment controllers and the service controllers

7:32inside of your Kubernetes cluster,

7:34as well as other types of resources like ingress

7:37controllers, can allow you to route traffic

7:40to different versions of your application

7:43that are running inside of your Kubernetes cluster.

7:45So knowing deployments, knowing service controllers,

7:48knowing ingress controllers-- those

7:50are going to be really important concepts

7:51as you're looking at these rollout strategies

7:54for new versions of your applications.

7:57Something else that's very important under application

7:59deployment is how to package up applications.

8:03Now, think with me for a minute just

8:05on general application packaging.

8:07So think of Ubuntu Linux.

8:10You've got the APT package manager.

8:12On Red Hat Linux, you've got the YUM package manager.

8:15In Amazon Linux, you've got the YUM package manager.

8:18On SUSE Linux, you've got the Zypper package manager.

8:21And on other platforms, on macOS, for example,

8:25if you're a developer and you're using the macOS platform,

8:27you've probably got a package manager

8:29called Homebrew installed.

8:30Homebrew is really useful because it's

8:32just a command line tool that you

8:33can use to install packages.

8:35Same thing on the Windows platform.

8:36If you're using Windows 11 like I am right here,

8:38you can fire up a terminal and, assuming

8:41that you've installed it, there's actually a package

8:43manager out there called Scoop.

8:45And you can do scoop install vscode, for example,

8:49and install Microsoft Visual Studio Code and a variety

8:52of other software packages.

8:54So a package manager, think about what

8:56it does at the basic level.

8:58So it's going to download some files.

9:01It's going to download some application files.

9:03It's going to extract those files onto the file system.

9:09And then it's going to do things like create shortcuts,

9:12for example, maybe in your Start menu,

9:14or inside of Finder on macOS.

9:17And it's going to give you some kind of entry point

9:20into that application.

9:22It's also going to perform some kind of configuration steps.

9:25So it might copy some configuration files

9:27onto the file system.

9:29It might alter a database and initialize a database

9:33with some configuration options.

9:34There's lots of different ways that applications

9:36can be configured.

9:37Maybe it sets some environment variables as well

9:40on your system.

9:41So there's lots of different ways

9:43that applications can be configured.

9:44And in Kubernetes, all of these things like downloading files

9:48or extracting files or creating an application entry point,

9:53creating a load balancer, configuring an application--

9:56these are all things that the Helm package manager,

9:59which is a third-party tool to Kubernetes itself--

10:03the Helm package manager is an open source utility

10:06that allows you to basically automate

10:08the process of installing different applications

10:10onto a Kubernetes cluster.

10:13So the Helm package manager is going

10:15to deploy something known as a chart.

10:18So these are all maritime-themed terms.

10:21You've got the Helm of the ship, where you can control the ship.

10:23And then you've got charts.

10:25You can think of star charts, for example,

10:27that may have been used back in the early days of running ships

10:33on the water and navigating ships on the water.

10:36And the Helm charts are basically

10:38going to give you the directions, the recipe,

10:40for how to install a particular software package

10:42onto a Kubernetes cluster.

10:45So it's going to contain all of the resources,

10:47like config maps, or service accounts, or cluster roles,

10:52or regular roles, and role bindings,

10:54and Pod definitions, deployment controllers, service

10:58controllers, load balancers, things like that.

11:01All of those different Kubernetes resources

11:03that are used to run and configure applications

11:06can get packaged up as something known as a Helm chart.

11:09And those Helm charts can be used to very easily spin up

11:13multiple instances of an application on a Kubernetes

11:16cluster.

11:17So if you're developing an application that's

11:19going to be deployed onto Kubernetes,

11:20it's actually very advantageous to think

11:23about using utilities such as Helm

11:26to simplify the process of deploying that application

11:29onto a Kubernetes cluster.

11:31Now, for the sake of the CKAD exam,

11:33you don't necessarily have to know how to actually write

11:36your own Helm charts, but you do want to make sure

11:39that you are familiar with the Helm package manager,

11:41and you know how to find different repositories

11:45for Helm, and you can figurre out

11:47how to install a release of a Helm chart

11:51onto your Kubernetes cluster, and then

11:53access that application once it's been

11:55deployed onto your cluster.

11:57So Helm package manager, really useful resource.

11:59And it's something that you want to know for CKAD.

12:03I hope this has been informative for you.

12:05And I'd like to thank you for viewing.

0:00[MUSIC PLAYING]

0:11Hey, guys, and welcome back.

0:12One of the other high-level learning objectives in CKAD

0:15is around application observability and maintenance.

0:19And so this is really going to center

0:21around things like how to make sure that your applications are

0:25healthy.

0:26So Kubernetes provides some mechanisms

0:29to confirm that your applications running in pods

0:32are healthy, that they're alive, that they've been initialized,

0:36that they're in a ready state.

0:38And so you can use these probes on your pod definitions

0:41to automate those health checks.

0:43And if necessary, Kubernetes can actually just kill off

0:46containers that are considered unhealthy,

0:48and then it can restart those containers to bring up

0:52a fresh instance of your application in the hopes

0:54that that will rectify any problems that your application

0:57may be experiencing.

0:59Now, there's also tools that you can

1:00use to monitor Kubernetes applications.

1:03There's things like the Kubernetes Dashboard.

1:05There's also third-party utilities out there,

1:07like Argo CD or KubeSphere, that can

1:10allow you to monitor applications running

1:13on your Kubernetes cluster.

1:15So you'll want to know how to gather things like metrics.

1:17You'll want to know how to gather application logs as well

1:20so that you can debug your application.

1:23Now, kubectl itself also has a built-in subcommand that

1:26allows you to monitor logs on your containers

1:31on your Kubernetes cluster.

1:32So by knowing how to retrieve logs from your pods

1:36as a developer, that's going to give you

1:39the tools that are necessary in order to debug

1:41any runtime-level problems that may be occurring, especially

1:45in production applications, where maybe you need to hop on

1:48to a production cluster, run some commands,

1:51gather those logs, and inspect what's

1:53going on with that application.

1:54But this actually ties into the earlier topic

1:57we were talking about around multicontainer pods as well.

1:59So as a good practice, you're going to want to make sure you

2:02have a logging agent installed on your cluster pods so that

2:05you can automate the process of gathering logs from

2:08your containers-- your application containers,

2:10rather--

2:11and then feed those logs up into a centralized logging store

2:15so that you can search them later on

2:17and not necessarily have to run commands against a production

2:21cluster in the event that you have

2:22a high-security environment that disallows developers

2:26from directly accessing the Kubernetes cluster itself.

2:30Something else you'll want to know

2:31is how to debug in Kubernetes.

2:33And so there's some really nice facilities

2:35that allow you to actually execute shell commands inside

2:38of pods directly.

2:40So in the event that you do have access to a production cluster,

2:43or maybe you're debugging inside of a dev environment,

2:46there's actually commands in kubectl

2:48that allow you to interface with a remote cluster.

2:51And you can actually run shell commands directly inside

2:53of a running container.

2:54And that will allow you to figure out what's going on.

2:58You can test the environment to figure out

3:01what environment variables are set, what kind of logs

3:03are being written, how is my application performing,

3:06how many resources--

3:08CPU and memory-- is this application consuming,

3:10and things like that.

3:11So knowing how to understand how your application is behaving

3:15on your Kubernetes cluster is going

3:17to be a really important thing.

3:18So make sure that you understand,

3:19at a high level, application observability and maintenance

3:23topics, both observability at a high level

3:26of the entire cluster and all the pods running on it,

3:29but also at the individual pod level as well--

3:31how to actually debug those.

3:33I hope this has been informative for you,

3:35and I'd like to thank you for viewing.

0:00[SOUND EFFECTS PLAYING]

0:11Hi, guys, and welcome back.

0:13So one of the other high-level topics in CKAD

0:15is around application environment, configuration,

0:18and security.

0:20Now, the terms "environment" and "configuration"

0:22have a lot of overlap, of course.

0:24Because when you're talking about configuration,

0:26you might actually be talking about things

0:28like environment variables.

0:29Right?

0:30So you can actually configure applications

0:31in a variety of different ways.

0:33You can use a database, a key value store, environment

0:36variables, as well as another resource inside of Kubernetes

0:40known as a "ConfigMap."

0:42And a ConfigMap is basically a separate resource

0:45that sits aside from your application pods

0:48and allows you to apply configurations

0:50to your Kubernetes pods.

0:53Some other things that you want to understand regarding

0:55applications on Kubernetes is things

0:57like authentication, authorization, and admission

1:00control.

1:00So when you're interacting with the Kubernetes API server,

1:03the API server is what you're actually

1:05communicating with when you use the kubectl command line

1:08utility.

1:09And so any time that you're making an API request

1:11to the API server, it's going to go through these phases

1:15of authentication.

1:16Who are you?

1:17Who are you that it's talking to the cluster?

1:19Authorization, do you have permission

1:21to perform whatever action it is that you're attempting

1:24to perform against the cluster?

1:26And then admission control, this is an advanced concept

1:29in Kubernetes that actually allows

1:31you to take an API call that's been authenticated

1:33and authorized.

1:35And then you can actually either perform transformations

1:37on the API call based on certain criteria,

1:40or you could abort the API call all together and reject it.

1:46So there's different options that you have there.

1:48And then something else you want to know

1:50as an application developer is how to set things

1:52like resource limits.

1:53So if you have an application that you're maybe

1:55migrating into containers, maybe more of a legacy application

1:59that has some bizarre behavior around resource consumption.

2:03Maybe, on a daily basis, it's consuming 100% CPU

2:08and maybe the application is still responding,

2:10but it's just consuming a lot more system resources

2:12than it really should be under normal circumstances.

2:15Well, Kubernetes actually has facilities

2:17that allow you to do things like set limits on resource

2:20consumption inside of your Kubernetes pod configuration.

2:24So that's one option.

2:25You can also set quotas as well.

2:27So you can set kind of cluster-level quotas so that

2:30people cannot use more resources than they're supposed to be

2:34on your cluster.

2:35And that helps just kind of having a fair share split

2:38of resources across the cluster, especially when you

2:40have multiple teams deploying applications

2:43onto a single cluster.

2:45Something else you'll want to know

2:46is around secrets management.

2:48So similar to ConfigMaps, you oftentimes

2:50have secret values, things like database passwords or API keys

2:55that your application is going to be using to communicate

2:57with external services.

2:59And so knowing how to store those secret values

3:01as "secret" resources in your Kubernetes cluster

3:05is going to be an important concept.

3:07Also, service accounts and security contexts

3:10are important concepts within the Kubernetes API server

3:13as sometimes your applications may

3:15need to communicate directly with the API server

3:19and perform different tasks against that API server,

3:22like listing resources that are configured on the cluster

3:25and things like that.

3:26So if you need to do that, then you

3:28need to understand how Kubernetes service accounts

3:30and security contexts work.

3:32And then one other topic is around Kubernetes custom

3:35resource definitions or CRDs.

3:37You don't necessarily need to know

3:38how to define your own custom resource definitions.

3:42However, there are lots of third-party applications

3:44out there that do install custom resource definitions

3:47and allow you to extend the Kubernetes API with custom

3:51resources that you can deploy.

3:53So rather than deploying a ConfigMap or a secret

3:56or a pod or a deployment controller

3:58or a service controller, a replica set,

4:01or all of the different types of built-in resources

4:03in Kubernetes, there's actually the ability

4:05for applications to extend the API

4:08and create totally custom types of resources.

4:12And you often see these types of things

4:13when you come across things like CI/CD systems, like Argo CD,

4:17for example.

4:18There will be things like custom pipeline resources

4:20that you can define in your Kubernetes cluster,

4:23so we'll take a look at how CRDs work.

4:26I hope this has been informative for you,

4:27and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back.

0:13So the last high-level learning domain

0:15for Certified Kubernetes Application Developer

0:17is around services and networking.

0:21Now, when it comes to load balancing resources

0:24on your Kubernetes cluster, it's really important

0:27to know how the service controller works.

0:30So the service controller sits in front

0:33of the pods that are exposing an application, right?

0:36So let's say that you have a web application,

0:38or maybe you're developing a web API that just listens on HTTP,

0:42and maybe you've got 10 pods running

0:45across all of your different worker nodes

0:47within your cluster, and you want

0:49to load balance all of this inbound network traffic

0:52against all 10 of those pods.

0:54And then maybe at certain peak times of demand, maybe

0:57it actually scales from 10 pods all the way up to 20 pods,

1:01right?

1:01So how do I load balance network traffic

1:04across these 10 to 20 pods that I

1:06might have running at any given point in time?

1:09Well, that's exactly where the service controller

1:12comes into play.

1:13You can do something called setting selector labels

1:16on your service controller.

1:19And then on the flip side, on your pods,

1:21you can actually put labels onto your pods,

1:23and then basically configure the service to route traffic

1:26to pods that have a certain selector.

1:28So that's a really important concept as an application

1:31developer, to know how to load balance network traffic

1:34across your application pods.

1:36Something else that's really important

1:38as an app developer is to know how

1:39to secure your application using something

1:41known as network policies.

1:43And network policies allow you to basically restrict

1:46what kind of network traffic can either

1:49come into or out of particular pods on your cluster.

1:53By default, Kubernetes allows pods to just communicate

1:56with each other unrestricted.

1:58And so it's really important, especially

1:59for high-security environments, to know

2:02how to leverage these network policy resources to limit

2:05the flow of network traffic, so that if a malicious user was

2:09to gain access to a particular pod on your cluster,

2:12that that malicious attacker would have limited attack

2:15surface inside of the cluster and would not

2:18be able to attack any other pod in the cluster,

2:21but only the pods that the compromised pod had access to.

2:26Something else you want to understand

2:28is how to route traffic using ingress controllers.

2:31And ingress controllers allow you

2:32to do things like map domain names to different services.

2:36So let's say that you're doing a blue/green deployment, right?

2:38And you're rolling out two different versions

2:40of your application.

2:41Maybe one version is going to be a beta version

2:44and one's going to be a production version.

2:46Well, using domain names-- like, let's

2:49say you've got beta.cbtnuggets.com

2:52and you've got prod.cbtnuggets.com.

2:55If you have two different versions of your application

2:57running and you want to ingress traffic

3:00to each of those two different versions of your application

3:02based on the DNS name that was requested

3:06for that particular service, then the ingress controller

3:09is what's going to allow you to accomplish that.

3:12So this is going to happen at layer 7.

3:15This is going to be HTTP-based routing that's going to occur.

3:19And so you want to know how to use these ingress rulers

3:21with your ingress controller.

3:23Nginx is a very popular open source ingress

3:26controller that's available.

3:27However, cloud providers also offer their own ingress

3:29controllers.

3:30Like Amazon Web Services has a layer 7 application load

3:34balancer that can also serve as an ingress controller.

3:37But you want to know how to set up these ingress controllers

3:40and ingress rules for those controllers

3:43throughout application traffic at the layer 7

3:47on the OSI model.

3:48I hope this has been informative for you,

3:50and I'd like to thank you for viewing.