Introduction to Certified Kubernetes Application Developer (CKAD)

0:11Hi, guys. My name is Trevor Sullivan, and welcome to this skill on the Certified Kubernetes Application Developer training course here at CBT Nuggets. Now, this is a followup training course to the Certified Kubernetes Administrator course that we released in March of 2022. So there's several different exams that I wanted to familiarize yourself with before we get too much into the weeds on CKD specifically. So if you head out to the Cloud Native Computing Foundation or see on CNCF's website, there are several different certifications that you can obtain on the Kubernetes platform.

0:52And there's three main ones that I wanted to call out. The first one is the Certified Kubernetes Administrator Certification. And this is really important for anybody who is going to be in a type of role where they are responsible for deploying or administering and maintaining a Kubernetes cluster. There's a lot of important concepts that are covered in CKA specifically that cover how to set up a cluster, how to set up a highly available cluster, and things like that. And not all of those concepts are necessarily important for you as a developer of applications that are simply going to be deployed onto a Kubernetes platform.

1:31So if you're not in a role where you are predominantly responsible for maintaining and monitoring and managing Kubernetes clusters, then CKA may not be the primary certification that you're looking for. The second certification that I wanted to draw your attention to is the one we're going to be talking about in this course, which is Certified Kubernetes Application Developer. And this one really hones in on a lot more topics that are centered around designing and deploying applications on top of the Kubernetes cluster.

2:02Now, that being said, there is certainly some foundational knowledge about Kubernetes that's covered in the Certified Kubernetes Administrator or CKA exam that might be relevant for you as a application developer who's deploying onto Kubernetes. However, if you are primarily looking for one out of these three primary exams to cover, then as an application developer, I would probably encourage you to stick with the Certified Kubernetes Application Developer Certification exam.

2:33The one other certification I wanted to call your call your attention to is the Certified Kubernetes Security Specialist. And this one, as the name implies, focuses a lot more on the security aspect of Kubernetes-- things like how to harden a Kubernetes cluster to ensure that it is secured from any malicious attackers, that malicious attackers are not able to gain unauthorized access to your Kubernetes clusters, how to do things like minimize vulnerabilities in microservices. And this actually has a lot of overlap with application developers, because as an app developer, when you are looking at reducing vulnerabilities of container-based applications being deployed on Kubernetes, minimizing those vulnerabilities from the original design is actually going to be a component of your application architecture.

3:21So keep in mind that there is going to be some overlap between these different certification exams. But the CKAD specifically is focused on people who are developing applications and trying to build pipelines to automate the deployment from code all the way to production pods running on Kubernetes. So CKS is a lot more security-focused. It talks about things like monitoring and logging and runtime security for your container runtime that you're using within your cluster, like containerd or the Docker runtime, for example.

3:53But what we're going to be focusing on in this course here at CBT Nuggets is Certified Kubernetes Application Developer. So just keep these certification exams in the back of your mind. You've got CKA. You've got CKAD. And then you've got CKS for security focus. And so that's kind of the high-level lay of the land as far as examinations go around the Kubernetes platform from the CNCF. Now, one of the nice things about the CNCF is that because it is part of the Linux Foundation, they're pretty transparent about the work that they are doing.

4:25And they actually have a repository over here on GitHub called GitHub.com/cncf/curriculum. And this repository actually contains several different PDF documents that cover the kind of topics that you are going to see in Certified Kubernetes Administrator, Certified Kubernetes Security Specialist, as well as the Certified Kubernetes Application Developer. So they provide this in PDF format here.

4:56It's basically just a two or three page document here that covers the high-level topics that we're going to be covering in the CKAD course. So I wanted to start off by going over this information with you from the curriculum and just talk about how you can kind of prepare mentally for the rest of this course, as well as prepare for the exam itself. Now, one thing I wanted to note is that the cost for the CKAD exam is $375. And the CNCF does actually include one free retake for that.

5:31So if you head out to their website, you'll see in the fine print right down here, the cost is $375, but it also does include one free retake. So if you're taking this exam and you're not sure if you're going to pass it on the first occasion, then maybe it's worth just kind of taking it, just to get a feel for how the exam format is, so that you can get more comfortable with it. And then if you don't happen to pass it on the first iteration, you always do get that one free retake as well. So just keep that in mind from a cost perspective, that even if you do pay that $375 but you don't pass it the first time, you still have that second chance without paying an additional fee on top of that $375.

6:12Now, something else that differs from the CNCF exams compared to other certification exams that I've personally taken in the past on things like the Microsoft platform as well as a bunch of the Amazon Web Services certification exams is that the CNCF exams are very much scenario-driven versus Q&A-driven. And what do I mean by that? Well, scenario-driven exams often are going to test very specifically your knowledge on a platform by actually having you execute commands within a shell environment to show that you actually understand the different concepts of a particular platform-- in this case, Kubernetes, of course.

6:55And so with these scenario-driven exams, you want to have a lot more hands-on experience than simply conceptual knowledge about a platform, as with some other vendor certifications out there. With AWS certifications, you can do a whole bunch of book learning and not really spend a lot of hands-on time with the platform, and you might actually be able to pass certain certification exams within the AWS ecosystem. Now, with Kubernetes, that is quite a bit different, because if you are not familiar with things like the kubectl command line utility, if you are not familiar with cluster architecture in Kubernetes and how you've got master nodes and worker nodes, if you're not familiar with the different components of a Kubernetes cluster-- like your API server, your scheduler component, your controller manager component that runs on your master nodes, as well as the kubelet component, which is responsible for actually running the pods on your worker nodes within your cluster, as well as static pods on your master nodes as well.

7:58If you're not familiar with a lot of those core concepts about Kubernetes and you try to take one of these scenario-driven exams, then you're probably going to find that you run into some challenges pretty quickly. When I first took the Certified Kubernetes Administrator exam and I first took one of these kind of scenario-driven exams, it really kind of opened my eyes to how specific they are with the different questions that they're asking. They're not just giving you three or four different options. They're giving you an objective that you have to accomplish, and then you have to actually run the commands and edit different text files and config files in your Kubernetes cluster in order to satisfy the requirements of that learning objective on the exam.

8:38So keep in mind that this is very different from many other vendor certification exams out there. And so you'll want to be mentally prepared before you actually attempt to take the exam for the first time to know that these are going to be scenario-driven questions, and that you're going to have to be familiar with shell commands, especially kubectl, since that's our primary interface for managing Kubernetes. And just have that knowledge going into this exam. So make sure that you spend a lot of hands-on time with Kubernetes. Don't just watch these videos in this course and expect that you're going to be able to pass.

9:09You really want to spin up your own clusters. Just the practice of spinning up and destroying clusters themselves is actually a really good experience as well, because that kind of forces you to kind of get your cluster back up and running on different cloud vendors out there. And I would encourage you to try different distributions of Kubernetes as well. Don't just settle for picking one distribution of Kubernetes and letting that be it. Sometimes, I've found that using Amazon EKS makes more sense. Sometimes I've found that using DigitalOcean's managed Kubernetes service gives me a little bit more awareness about some other open source tools within the Kubernetes ecosystem.

9:46For example, they use an open source utility called Cilium on their clusters by default that EKS does not use. Also, EKS has things that are specific to it, like IAM integration with AWS Identity and Access Management. And that simply doesn't exist in the DigitalOcean ecosystem. It doesn't have the same concept of IAM roles like AWS does. So play around with some of the different distributions of Kubernetes out there, different managed cloud providers, like DigitalOcean, Linode, Microsoft Azure, AKS, EKS from Amazon Web Services, and maybe even Google's Kubernetes Engine GKE as well.

10:23And then if you're looking for other distributions of Kubernetes that you can run locally, you might want to look at a distribution like K3S. K3S was actually originally developed by Rancher Labs, and it's a really nice lightweight distribution to run Kubernetes locally on your own systems. So that's one option. You've also got Kubernetes in Docker or the kind project. And this is another project that will actually allow you to spin up a Kubernetes cluster inside of Docker itself. So you're basically running Kubernetes as an array of containers.

10:55So that's kind of a cool option that you have as well. And then one of the easiest ways to get your Kubernetes cluster up and running is actually just to install Docker desktop here as well. So Docker desktop actually includes its own distribution of Kubernetes. So that's yet another option that you have to run Kubernetes locally. So there's a bunch of different distributions out there. But I would encourage you to practice with different distributions. Don't just use Google Kubernetes Engine and think, OK, I know enough. Play around with K3S. Play around with the built-in Docker desktop distribution of Kubernetes as well.

11:29And that'll just give you more breadth of experience and understand some of the nuances between how different distributions of Kubernetes works. So that's just something I wanted to kind of point out as you are preparing for the CKAD exam. Now, CKAD, as the name implies, is really geared more towards application developers. So the primary topics that are going to be covered are things around how to build container images and deploy container images as Kubernetes pods out into your cluster. There's a lot less emphasis on things like networking and cluster deployment and cluster monitoring and that kind of stuff.

12:06However, you are still going to want to know how to debug applications that are running in Kubernetes clusters, because as an application developer, if something goes wrong with one of your application pods, then you're going to need to things like, how do I get logs from pods? How do I run shell commands in pods, if I need to, in order to do investigative work, to gather data, so that I can debug any kind of problems that might be occurring in my Kubernetes-based applications? There are also some Kubernetes security topics that are going to be covered as well in CKAD.

12:40And we'll talk about those in a little bit more depth here in the overview skill here. But these are going to be a little bit more centered around things like how do I authenticate to the Kubernetes API server? How do I use security contexts? How do I use secrets? How do I create config maps to configure my applications in a more agnostic fashion? And things like that. So the primary topics in CKAD are going to be geared towards application developers that are working with a DevOps team that's ultimately going to be deploying production-scale applications onto Kubernetes clusters.

13:16Anyways, we're going to drill into these next videos and cover some of the topics in a little bit more depth. We'll cover just at a high level what some of these learning objectives are for the CKAD exam, and make sure that as you continue your learning journey in preparation for the CKAD exam, that you'll understand what these high-level topics are. And then in our other skills within the CKAD course, we're going to drill much deeper and actually get hands-on time with some of these concepts in Kubernetes so that you can go into CKAD best prepared so that you can successfully pass that exam.

13:52I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back. So one of the high-level learning objectives in the certified Kubernetes Application Developer Certification exam is around application design and build in Kubernetes. So this is going to cover a lot of the most important concepts around how to actually build container images in your Kubernetes cluster, and then deploy those container images out to your Kubernetes cluster. Now, some of the specific topics that are going to be covered under this learning objective are things like defining Dockerfiles.

0:44So you're going to want to know how to create a Dockerfile. You want to understand what different base images are out there in the ecosystem to build off of to inject your application code into. Now, if you head out to a popular registry known as the Docker Hub over at hub.docker.com, this is where the bulk of base images are going to come from. And there's lots of different base images out on Docker Hub, anywhere from Linux distribution based options, like Ubuntu Linux, or if you search for Alpine Linux, there's Alpine-based images out here as well.

1:20But there's also container images out here that allow you to base your applications off of specific runtimes. So if you're building, let's say, a Python-based application, then you might want to start with one of the official Python-based images and then simply inject your application code, install any necessary Python dependencies from Python Package Index into your container image, and then use that as your basis for building your own custom application images. Similarly, let's say maybe you're a JavaScript developer, and so you're using the Node.js runtime in order to execute your application.

1:54In that case, you might actually use one of the official node-based images, and then inject your application code install your dependencies from your package.json file, and then set your command or your entry point into that container, and then that would build out to your container image. So knowing some of the different options for base images out there, knowing how to construct a Dockerfile, also knowing how to use the Dockerfile reference is a really good piece of documentation that's going to be helpful as you are learning how to build container images, because the Dockerfile reference is going to give you the authoritative list of commands that are available to use inside of your Dockerfile.

2:36And these are going to allow you to do different things, like install dependencies, install packages inside of your container image. You're going to be able to copy files from your container context into your-- or I should say your Docker context-- into your container image before you actually package it up. You'll also be able to set things like your working directory as well, where your application resides so that you can write temporary files in there or read configuration files.

3:06You can set arguments for your Dockerfiles as well. So knowing how to use the Dockerfile reference documentation to really find the specific Dockerfile commands that are going to help you to construct your container image-- this is going to be an excellent resource if you are-- especially if you're new to container building, but also if you're an experienced container developer, but there is maybe some lesser known commands that you just don't use very often inside of your Dockerfiles. Then the Dockerfile reference documentation is going to be a great place to refer back to any time that you are using different Dockerfile commands inside of your Dockerfiles.

3:44So knowing how to build container images is going to be really important. Of course, you can get a lot of practice building container images locally on your dev system without even using Kubernetes. So if you just have Docker Desktop installed on your local dev system, you can call the Docker CLI tool. If I just fire up a shell here, I can run the Doctor CLI tool here on my Windows 11 dev system. And I can do a Docker build command here. And I don't necessarily have to be using Kubernetes at this point to simply know how to create Dockerfiles and how to build container images.

4:19However, once you get around to actually deploying containers as pods onto your Kubernetes cluster, that's where you're really going to want to have a deeper knowledge about how to push container images to alternative registries. So maybe you're using Amazon Elastic Container Registry, which is a managed service that allows you to host your container images. Or maybe you're going out to the Docker Hub and maybe you're hosting private container images, instead of just the public images that are available out here.

4:52And so you'll need to things like, how do I deploy private container images from the Docker Hub or some other private registry? Maybe you're using even a Red Hat's Quay.io. So this is another example of a container image registry, where you can store your container images, host them out there, simply storing them on a managed service. And then, when you actually deploy pods onto your Kubernetes cluster, you can configure those pods to actually download container images from a registry like Quay.io, or Amazon Elastic Container Registry, or the Docker Hub as private images, or a whole bunch of other container registries out there as well.

5:30A lot of the cloud vendors that offer managed Kubernetes services also have a managed container registry. So for example, DigitalOcean-- if you head out to DigitalOcean and you search for just the registry, you'll see that they do have a managed registry service here as well. So you can pick which registry service it is that you want to use for your particular team. Even if you're using Amazon Elastic Kubernetes service or Microsoft Azure Kubernetes service to actually deploy and run your cluster, that doesn't necessarily mean that you have to use the same managed service for using your registry as well.

6:09So just keep that in mind, that you do have a choice for where to run your Kubernetes cluster, as well as where to run your registry. Another high-level learning objective that you're going to come across under application design and build in Kubernetes is how to deploy pods as Jobs and CronJobs. Now, oftentimes, when you are deploying pods onto your Kubernetes cluster, you'll use a construct like a deployment controller, and that will allow you to scale your application. And then you can typically use what's known as a service controller, which is-- you can think of it like a load balancer that allows you to load balance incoming network traffic to the different pods for your application.

6:49However, Kubernetes also has a construct known as Jobs and CronJobs. So if you need to run pods in the background, and they're basically just maybe queue processors or they're just doing some kind of background processing-- think of things like maybe a video processing application that's basically just taking video files and running conversions-- or maybe if you need to run batch processes-- maybe you've got a batch process that generates reports every night at 2:00 AM local time or something like that. So in those cases, you can actually use a construct known as a CronJob resource in your Kubernetes cluster, and that will allow you to automatically spin up a pod on a schedule so that you don't have to run a persistent background job and waste compute resources to run those pods, even if they're just sleeping.

7:39So instead of having a long-running job that just sleeps for hours on end and just wastes compute resources in your cluster, you can instead just tell Kubernetes that you want to run a pod on a Cron schedule. And a Cron schedule will allow you to define a time-based expression that determines at what times of day the Kubernetes scheduler will go ahead and spin up a pod and actually schedule it onto one of your cluster worker nodes. So using these constructs to run background jobs on your cluster, and not just APIs, or web front ends, or other services that end users are going to be hitting from outside the cluster, you can also run just internal jobs inside of your cluster as well using both the Job resource as well as CronJobs resources as well.

8:29Another important concept that you're going to want to cover in application design and build is how to use multi-container pod design patterns. Now, Kubernetes pods are going to allow you to spin up more than a single container. So a pod is basically one or more containers that are all going to get scheduled onto the same node. When the Kubernetes scheduler schedules a pod to run on a particular worker node in your cluster, it's going to look at all of the containers that are inside of that pod spec or that pod definition in your YAML manifest files, and it's going to schedule all of the containers for that pod on the same node so that they're running locally to each other.

9:15Now, some of the common design patterns that you're going to see for multi-container pods are things like logging agents. So when you have an application-- let's say maybe a web application, or an API server, or maybe you even have a background job or maybe a CronJob that's running. And you logging information from that application. So maybe you're logging API requests to an API and writing those out to a file, or maybe every time that you have a background job pod that is processing videos, maybe it's running some kind of conversion process on videos with FFmpeg.

9:54It's going to spit out some log messages to indicate when it's finished processing a particular video file. And so what you can do is actually capture those logs that are coming from your applications by using what's known as a sidecar technique. So rather than just having a single pod or a single container inside of your pod, you can actually set up a secondary-- what's known as a sidecar container, which is basically just a second container definition inside of your multi-container pod that is going to be responsible solely for gathering logs from the primary container that's actually running your application inside of the pod, and then taking those logs and forwarding those logs over to some centralized logging service.

10:41So that's the sidecar design pattern, where you have some kind of logging agent that's running in a secondary container in your multi-container pod spec. And that logging agent can then take those logs, and then it can either perform conversions on those logs and do some kind of log processing and then send it to your centralized logging store, or it can just send it directly to that log store without doing any processing ahead of time. So one popular logging agent out there is known as Fluentd.

11:11That is a popular open-source utility that allows you to grab logs and then forward them to some kind of destination. There's also a smaller sister project to that known as Fluent Bit, or there's also another project from the Elastic Stack called the Elastic-- or sorry-- called Logstash. And Logstash works alongside Elasticsearch. So let me type Elasticsearch, and then Logstash. And this Logstash is an open-source utility that, again, allows you to capture logs from a variety of sources, then perform some kind of conversion on those logs, and then send them to some kind of destination.

11:51So knowing how to do things like that sidecar design pattern are going to be important for application developers, since, for the purpose of separation of concerns, it's a good idea to have a separate container that's actually doing the logging, rather than building all of the logging logic directly into your application container, as that could bloat your application and just increase the complexity of debugging your application. Now, pods also supports something known as an init container. So when your pods are originally scheduled onto a worker node, you can actually create what's known as an init container, and that will initialize the pods state.

12:31And this is really useful if you need to pre-populate a application with some data. So maybe you're running something like a Redis cache instance, or maybe you're running a database server or something like that, and you need to load some data into that application. Well, what you can do is create this thing called an init container, and that could have some kind of data loading script that can read data from a source-- maybe a file or some other network resource-- and then load that data into your primary application pod inside of your multi-container pod design pattern.

13:05And then that can pre-populate data into your application, into your stateful database, or key-value store or things like that, and then that will allow you to reduce the amount of automation work that you need to do after the fact in order to initialize the state of that pod. So it's important to things like sidecar containers and init containers in your multi-container pod design patterns. Something else you'll want to know as an application developer, when it comes to things like stateful applications-- especially things like databases or value stores, like [INAUDIBLE] or Redis cache, for instance-- is how to utilize volumes.

13:48So in Kubernetes, you can actually separate your application logic from your storage by creating what's known as a persistent volume. And then you can create something known as a persistent volume claim. And you can actually bind a persistent volume to an application pod, and then any data that is mapped into the file system, into that persistent volume will actually live outside of the lifecycle of a pod. Now, this is especially important for stateful applications.

14:20So imagine that you're running MySQL inside of a pod. All right, so if you run MySQL inside of a pod and you are writing data into it and creating databases, and tables, and rows inside of tables, then all of this data that you create as part of this MySQL database instance is going to need to be persisted, even if, for some reason, that pod were ever to die. So if your worker nodes inside of your cluster randomly get destroyed, for example-- let's say that maybe there's an operating system level corruption, or memory corruption, or something like that-- well, that pod could die that's running MySQL.

15:01But then the Kubernetes Engine is going to detect that your pod has died, and it will automatically recreate a new pod running MySQL. But you don't want to start with a bare bones MySQL instance. You actually want it to load your database that you previously had running with all of your data, your table definitions, and all of your rows inside of it. Or maybe same thing with a graph database, like Neo4j. Maybe you're running Neo4j inside of a Kubernetes pod as well, and you create lots of nodes and relationships between nodes.

15:34And if, for some reason, your pod that's running Neo4j were to die as a result of a worker node being affected, then, of course, you don't want to have to recreate all your nodes and relationships. You want to be able to restore that database from where it left off when the pod died, and simply pick up from there and continue running your Neo4j instance. And so this is where persistent volumes are very important, because that's what's going to allow you to write your database files into different locations onto the file system, and then write that into external storage that's outside of the cluster.

16:10However, you can attach that storage to the cluster so that you can utilize the data inside of it. So that's how persistent volumes work at a high level. And then something else that you can do is well as use ephemeral volumes. So if you need to share data between containers in a multi-container pod design, then ephemeral volumes that can actually allow you to share data on a particular system path so that more than one container within a pod is able to access that information. So that's going to be really helpful if you have an application that's logging information.

16:44Maybe you've got a web server, and that's logging it to /mydata/mylogs or something. And then maybe you've got two different containers that one of them is writing to that location on the file system and one is a logging agent that's actually reading data from this file system location. And that's going to be your logging agent that will then forward those logs over to a different location. So if you need to share storage between containers in a pod, then you'll want to know how ephemeral volumes work in Kubernetes as well.

17:20So that's pretty much it for the application design and build in Kubernetes learning objective for CKAD. I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hi, guys, and welcome back. So one of the other high level topics that's going to be covered in the Certified Kubernetes Application Developer Certification exam is around application deployment. So whereas we covered some of the application design and build principles in the previous learning objective, the application deployment learning objective is centered around how to actually get applications deployed onto a Kubernetes cluster. So once you've got your application packaged up as a container image, you've got it pushed up to your container registry that you're using, could be an external registry or an internal registry, now how do you actually deploy production applications out to your Kubernetes cluster?

0:52So one of the most important topics here is going to be something known as the deployment controller. If you are deploying applications that need to be scalable out to your Kubernetes cluster, the deployment controller, along with the ReplicaSet that's a child resource of the deployment controller-- knowing how these constructs work in Kubernetes is going to be incredibly important because the deployment controller is going to enable you to perform a couple of different types of deployments. And that is going to be the blue-green and canary deployments here.

1:25So let's talk really quickly about what these deployments are. So what is a blue-green deployment for starters? Well, let's say that you've got an old version of an application and a new version of an application. And you want to basically get your new version of your application deployed side by side with the current or old production version of your application. I'm actually going to change old to current. So I've got my current version, and I've got my new version of this application. And I want to get all of my users over to this new version of my application.

1:58Well, the blue-green deployment model is basically where you spin up a second copy of your application side by side with the current version that's already running in production. So you've got all your-- 100% of your traffic that's all hitting this current version, you deploy a second instance of your application on your Kubernetes cluster, could be the same cluster, and you then have two versions of the application running side by side, your current version and your new version.

2:29And then in a blue-green deployment, this is where you would actually cut over your traffic from the current version of your application over to the new version of your application. The reason they call it blue-green is because you have two different copies of your application. One's blue, your original version. The other is green. That's your green field or new version of your application that you're trying to get your users onto. And then when you perform a cut over, that's when you're basically cutting over that network traffic and telling all of your users, OK, I know you've been going to this old version of the application, but now I'm going to redirect you.

3:04And I'm going to cut you over to this new version of the application. The nice thing about doing a blue-green deployment is that if anything were to go wrong with that green or new version of your application, then you can actually just cut your users back over to the original version, the current version, that you were running previously, or that blue version, and that is going to allow you to get back to a known, good working state. So by doing blue-green deployments, you've got two copies of your application running side by side. And then you can cut your users over to that new version.

3:36If you have any problems, you can roll back to the previous version with relative ease. And then if you want to, after you've upgraded your users to that new green version, you can go ahead and then just shut down the blue or current version of your application. And then you'll only be left with your new version. And then that new version, once all of your users are successfully cut over to it, that new version actually becomes the next current version. And so then the next time that you go through another iteration where you're going to release a new version of your application, that new green version that's now become the current version will then become the blue version and then you'll have another new version that replaces the green.

4:18And so you'll continuously go through that process and iterate and continuously be adding new versions of your application. Now, a canary deployment is very similar to a blue-green deployment. However, there is one key difference with the canary deployment versus a blue green deployment. So when people talk about blue-green deployments, they're typically talking about spinning up two environments and then cutting your traffic over to that new green environment. With a canary deployment, this is a slight variation where you still have a blue-green version running side by side.

4:50However, with a canary deployment, you take a small percentage of your traffic, so maybe 5% of your traffic you want to redirect to the new version of your application. And the reason that you do this in a canary deployment is to minimize the impact of redirecting all of your users directly to the new application version. Imagine that your old application version-- or, sorry-- your new application version actually introduces a new bug. Or maybe there's some feature that's missing from that new version that was present in the original or current version of your application.

5:28Well, if that were to happen in a blue-green deployment scenario, and you cut your application over from the current version to the new version, then that's going to impact 100% of your users. And that could be really catastrophic for a business that is running mission-critical applications. With a canary deployment, you can mitigate that risk by redirecting a small percentage of your traffic into the new application version. So you still spin up both the current and the new version of your application, but instead of redirecting all the traffic, you just redirect some of it.

6:02Now, after you've redirected, let's say, maybe 5%, or maybe 3%, or whatever number it is that you choose-- once you've redirected a portion of your network traffic over to this new version, you've monitored your logs, you've monitored your data storage mechanism-- if you're using MySQL or NoSQL database or a graph database, you want to just check the integrity of your data. You want to look at your application metrics. Make sure that there's no unexpected resource hogs in the new version of your application.

6:32Once you've verified that everything is working great for that initial 3% of users, then you can increase it. So I'm going to take it, maybe, from 3% and maybe raise it to 15% or maybe 10%, just to be a little bit more cautious. So with canary deployments, you're basically progressively increasing, over time, the percentage of traffic that you are sending over to a new version of your application. Now, eventually, you'll hit 100% of all of your traffic. And so once 100% of all of your traffic has successfully been migrated to the new version of your application, you can then spin down the old version of your application.

7:12And then once you've done that, you can continue to iterate on that same process, spin up another new version of your application, and then spin down the old version of the application. And by using that canary rollout process, you're actually minimizing the risk of cutting all of your network traffic over. And the deployment controllers and the service controllers inside of your Kubernetes cluster, as well as other types of resources like ingress controllers, can allow you to route traffic to different versions of your application that are running inside of your Kubernetes cluster.

7:45So knowing deployments, knowing service controllers, knowing ingress controllers-- those are going to be really important concepts as you're looking at these rollout strategies for new versions of your applications. Something else that's very important under application deployment is how to package up applications. Now, think with me for a minute just on general application packaging. So think of Ubuntu Linux. You've got the APT package manager. On Red Hat Linux, you've got the YUM package manager. In Amazon Linux, you've got the YUM package manager.

8:18On SUSE Linux, you've got the Zypper package manager. And on other platforms, on macOS, for example, if you're a developer and you're using the macOS platform, you've probably got a package manager called Homebrew installed. Homebrew is really useful because it's just a command line tool that you can use to install packages. Same thing on the Windows platform. If you're using Windows 11 like I am right here, you can fire up a terminal and, assuming that you've installed it, there's actually a package manager out there called Scoop. And you can do scoop install vscode, for example, and install Microsoft Visual Studio Code and a variety of other software packages.

8:54So a package manager, think about what it does at the basic level. So it's going to download some files. It's going to download some application files. It's going to extract those files onto the file system. And then it's going to do things like create shortcuts, for example, maybe in your Start menu, or inside of Finder on macOS. And it's going to give you some kind of entry point into that application. It's also going to perform some kind of configuration steps.

9:25So it might copy some configuration files onto the file system. It might alter a database and initialize a database with some configuration options. There's lots of different ways that applications can be configured. Maybe it sets some environment variables as well on your system. So there's lots of different ways that applications can be configured. And in Kubernetes, all of these things like downloading files or extracting files or creating an application entry point, creating a load balancer, configuring an application-- these are all things that the Helm package manager, which is a third-party tool to Kubernetes itself-- the Helm package manager is an open source utility that allows you to basically automate the process of installing different applications onto a Kubernetes cluster.

10:13So the Helm package manager is going to deploy something known as a chart. So these are all maritime-themed terms. You've got the Helm of the ship, where you can control the ship. And then you've got charts. You can think of star charts, for example, that may have been used back in the early days of running ships on the water and navigating ships on the water. And the Helm charts are basically going to give you the directions, the recipe, for how to install a particular software package onto a Kubernetes cluster.

10:45So it's going to contain all of the resources, like config maps, or service accounts, or cluster roles, or regular roles, and role bindings, and Pod definitions, deployment controllers, service controllers, load balancers, things like that. All of those different Kubernetes resources that are used to run and configure applications can get packaged up as something known as a Helm chart. And those Helm charts can be used to very easily spin up multiple instances of an application on a Kubernetes cluster.

11:17So if you're developing an application that's going to be deployed onto Kubernetes, it's actually very advantageous to think about using utilities such as Helm to simplify the process of deploying that application onto a Kubernetes cluster. Now, for the sake of the CKAD exam, you don't necessarily have to know how to actually write your own Helm charts, but you do want to make sure that you are familiar with the Helm package manager, and you know how to find different repositories for Helm, and you can figurre out how to install a release of a Helm chart onto your Kubernetes cluster, and then access that application once it's been deployed onto your cluster.

11:57So Helm package manager, really useful resource. And it's something that you want to know for CKAD. I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hey, guys, and welcome back. One of the other high-level learning objectives in CKAD is around application observability and maintenance. And so this is really going to center around things like how to make sure that your applications are healthy. So Kubernetes provides some mechanisms to confirm that your applications running in pods are healthy, that they're alive, that they've been initialized, that they're in a ready state.

0:38And so you can use these probes on your pod definitions to automate those health checks. And if necessary, Kubernetes can actually just kill off containers that are considered unhealthy, and then it can restart those containers to bring up a fresh instance of your application in the hopes that that will rectify any problems that your application may be experiencing. Now, there's also tools that you can use to monitor Kubernetes applications. There's things like the Kubernetes Dashboard. There's also third-party utilities out there, like Argo CD or KubeSphere, that can allow you to monitor applications running on your Kubernetes cluster.

1:15So you'll want to know how to gather things like metrics. You'll want to know how to gather application logs as well so that you can debug your application. Now, kubectl itself also has a built-in subcommand that allows you to monitor logs on your containers on your Kubernetes cluster. So by knowing how to retrieve logs from your pods as a developer, that's going to give you the tools that are necessary in order to debug any runtime-level problems that may be occurring, especially in production applications, where maybe you need to hop on to a production cluster, run some commands, gather those logs, and inspect what's going on with that application.

1:54But this actually ties into the earlier topic we were talking about around multicontainer pods as well. So as a good practice, you're going to want to make sure you have a logging agent installed on your cluster pods so that you can automate the process of gathering logs from your containers-- your application containers, rather-- and then feed those logs up into a centralized logging store so that you can search them later on and not necessarily have to run commands against a production cluster in the event that you have a high-security environment that disallows developers from directly accessing the Kubernetes cluster itself.

2:30Something else you'll want to know is how to debug in Kubernetes. And so there's some really nice facilities that allow you to actually execute shell commands inside of pods directly. So in the event that you do have access to a production cluster, or maybe you're debugging inside of a dev environment, there's actually commands in kubectl that allow you to interface with a remote cluster. And you can actually run shell commands directly inside of a running container. And that will allow you to figure out what's going on. You can test the environment to figure out what environment variables are set, what kind of logs are being written, how is my application performing, how many resources-- CPU and memory-- is this application consuming, and things like that.

3:11So knowing how to understand how your application is behaving on your Kubernetes cluster is going to be a really important thing. So make sure that you understand, at a high level, application observability and maintenance topics, both observability at a high level of the entire cluster and all the pods running on it, but also at the individual pod level as well-- how to actually debug those. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[SOUND EFFECTS PLAYING] Hi, guys, and welcome back. So one of the other high-level topics in CKAD is around application environment, configuration, and security. Now, the terms "environment" and "configuration" have a lot of overlap, of course. Because when you're talking about configuration, you might actually be talking about things like environment variables. Right? So you can actually configure applications in a variety of different ways.

0:33You can use a database, a key value store, environment variables, as well as another resource inside of Kubernetes known as a "ConfigMap." And a ConfigMap is basically a separate resource that sits aside from your application pods and allows you to apply configurations to your Kubernetes pods. Some other things that you want to understand regarding applications on Kubernetes is things like authentication, authorization, and admission control. So when you're interacting with the Kubernetes API server, the API server is what you're actually communicating with when you use the kubectl command line utility.

1:09And so any time that you're making an API request to the API server, it's going to go through these phases of authentication. Who are you? Who are you that it's talking to the cluster? Authorization, do you have permission to perform whatever action it is that you're attempting to perform against the cluster? And then admission control, this is an advanced concept in Kubernetes that actually allows you to take an API call that's been authenticated and authorized. And then you can actually either perform transformations on the API call based on certain criteria, or you could abort the API call all together and reject it.

1:46So there's different options that you have there. And then something else you want to know as an application developer is how to set things like resource limits. So if you have an application that you're maybe migrating into containers, maybe more of a legacy application that has some bizarre behavior around resource consumption. Maybe, on a daily basis, it's consuming 100% CPU and maybe the application is still responding, but it's just consuming a lot more system resources than it really should be under normal circumstances. Well, Kubernetes actually has facilities that allow you to do things like set limits on resource consumption inside of your Kubernetes pod configuration.

2:24So that's one option. You can also set quotas as well. So you can set kind of cluster-level quotas so that people cannot use more resources than they're supposed to be on your cluster. And that helps just kind of having a fair share split of resources across the cluster, especially when you have multiple teams deploying applications onto a single cluster. Something else you'll want to know is around secrets management. So similar to ConfigMaps, you oftentimes have secret values, things like database passwords or API keys that your application is going to be using to communicate with external services.

2:59And so knowing how to store those secret values as "secret" resources in your Kubernetes cluster is going to be an important concept. Also, service accounts and security contexts are important concepts within the Kubernetes API server as sometimes your applications may need to communicate directly with the API server and perform different tasks against that API server, like listing resources that are configured on the cluster and things like that. So if you need to do that, then you need to understand how Kubernetes service accounts and security contexts work.

3:32And then one other topic is around Kubernetes custom resource definitions or CRDs. You don't necessarily need to know how to define your own custom resource definitions. However, there are lots of third-party applications out there that do install custom resource definitions and allow you to extend the Kubernetes API with custom resources that you can deploy. So rather than deploying a ConfigMap or a secret or a pod or a deployment controller or a service controller, a replica set, or all of the different types of built-in resources in Kubernetes, there's actually the ability for applications to extend the API and create totally custom types of resources.

4:12And you often see these types of things when you come across things like CI/CD systems, like Argo CD, for example. There will be things like custom pipeline resources that you can define in your Kubernetes cluster, so we'll take a look at how CRDs work. I hope this has been informative for you, and I'd like to thank you for viewing.

0:11Hey, guys, and welcome back. So the last high-level learning domain for Certified Kubernetes Application Developer is around services and networking. Now, when it comes to load balancing resources on your Kubernetes cluster, it's really important to know how the service controller works. So the service controller sits in front of the pods that are exposing an application, right? So let's say that you have a web application, or maybe you're developing a web API that just listens on HTTP, and maybe you've got 10 pods running across all of your different worker nodes within your cluster, and you want to load balance all of this inbound network traffic against all 10 of those pods.

0:54And then maybe at certain peak times of demand, maybe it actually scales from 10 pods all the way up to 20 pods, right? So how do I load balance network traffic across these 10 to 20 pods that I might have running at any given point in time? Well, that's exactly where the service controller comes into play. You can do something called setting selector labels on your service controller. And then on the flip side, on your pods, you can actually put labels onto your pods, and then basically configure the service to route traffic to pods that have a certain selector.

1:28So that's a really important concept as an application developer, to know how to load balance network traffic across your application pods. Something else that's really important as an app developer is to know how to secure your application using something known as network policies. And network policies allow you to basically restrict what kind of network traffic can either come into or out of particular pods on your cluster. By default, Kubernetes allows pods to just communicate with each other unrestricted. And so it's really important, especially for high-security environments, to know how to leverage these network policy resources to limit the flow of network traffic, so that if a malicious user was to gain access to a particular pod on your cluster, that that malicious attacker would have limited attack surface inside of the cluster and would not be able to attack any other pod in the cluster, but only the pods that the compromised pod had access to.

2:26Something else you want to understand is how to route traffic using ingress controllers. And ingress controllers allow you to do things like map domain names to different services. So let's say that you're doing a blue/green deployment, right? And you're rolling out two different versions of your application. Maybe one version is going to be a beta version and one's going to be a production version. Well, using domain names-- like, let's say you've got beta.cbtnuggets.com and you've got prod.cbtnuggets.com. If you have two different versions of your application running and you want to ingress traffic to each of those two different versions of your application based on the DNS name that was requested for that particular service, then the ingress controller is what's going to allow you to accomplish that.

3:12So this is going to happen at layer 7. This is going to be HTTP-based routing that's going to occur. And so you want to know how to use these ingress rulers with your ingress controller. Nginx is a very popular open source ingress controller that's available. However, cloud providers also offer their own ingress controllers. Like Amazon Web Services has a layer 7 application load balancer that can also serve as an ingress controller. But you want to know how to set up these ingress controllers and ingress rules for those controllers throughout application traffic at the layer 7 on the OSI model.

3:48I hope this has been informative for you, and I'd like to thank you for viewing.