WEBVTT 1 00:00:00.080 --> 00:00:02.240 Ever feel like you're trying to manage I don't know, 2 00:00:02.600 --> 00:00:05.719 a huge complex project, maybe like building something intricate and 3 00:00:05.719 --> 00:00:10.519 you got hundreds of moving parts. It's easy to get overwhelmed. Right, Well, 4 00:00:10.560 --> 00:00:13.439 today we're diving into a really powerful tool that helps 5 00:00:13.439 --> 00:00:17.879 manage exactly that kind of complexity, but specifically in the cloud, 6 00:00:17.960 --> 00:00:22.399 Azure Kubernetes service. You'll often hear it called AKS. Our 7 00:00:22.480 --> 00:00:24.640 mission really for this deep dive is to pull out 8 00:00:24.640 --> 00:00:28.280 the most crucial insights from the book Mastering Azure Kuberneti 9 00:00:28.320 --> 00:00:32.039 Service AKS by Ibichek Mishra. We're going to try and 10 00:00:32.079 --> 00:00:35.000 demystify things a bit. We'll look at how software components 11 00:00:35.039 --> 00:00:37.960 get packaged up neatly and then how they're intelligently managed 12 00:00:38.000 --> 00:00:41.520 scaled by this super smart system in the Azure Cloud. 13 00:00:42.039 --> 00:00:44.439 Think of this as your FastTrack to understanding what makes 14 00:00:44.479 --> 00:00:46.320 AKS tick and why it's so important. 15 00:00:46.600 --> 00:00:48.799 Yeah, that's a great way to put it. We'll explore 16 00:00:48.840 --> 00:00:52.640 the foundations, you know, the basic ideas, understand the core architecture, 17 00:00:53.159 --> 00:00:56.799 and really uncover how AKS tackles those big real world challenges, 18 00:00:56.840 --> 00:01:01.520 things like scalability, keeping things reliable, deploying a thing, especially 19 00:01:01.520 --> 00:01:04.760 when you've got these complex applications. We want to get 20 00:01:04.760 --> 00:01:07.560 to the heart of why this shift to containers and 21 00:01:07.680 --> 00:01:11.359 orchestration is happening, and crucially, what it actually enables for 22 00:01:11.400 --> 00:01:15.439 you today. This deep dive, it's basically your roadmap to 23 00:01:15.599 --> 00:01:18.480 getting up to speed quickly on a topic that's pretty 24 00:01:18.480 --> 00:01:19.319 critical right now. 25 00:01:19.599 --> 00:01:22.239 Okay, let's unpack this journey then, starting right at the beginning, 26 00:01:22.239 --> 00:01:26.359 before we even get to Kubernetes, this orchestrator. Yeah, we 27 00:01:26.400 --> 00:01:31.400 need to understand the basic building blocks containers. What exactly 28 00:01:31.560 --> 00:01:34.239 was the problem they were designed to solve? Why are 29 00:01:34.280 --> 00:01:35.200 they everywhere now? 30 00:01:35.640 --> 00:01:38.400 Right? Historically to have this constant headache, developers would build 31 00:01:38.400 --> 00:01:40.400 something tested and s where it works on my machine. 32 00:01:40.560 --> 00:01:43.719 Oh, I've heard that one and lived it, probably exactly. 33 00:01:44.120 --> 00:01:46.799 Then it moves to a test server or worse, production, 34 00:01:47.040 --> 00:01:52.280 and suddenly it breaks. The environment's just slightly different, maybe 35 00:01:52.319 --> 00:01:55.319 a library version is off, or a canfig file isn't 36 00:01:55.359 --> 00:01:57.439 quite right. It was a constant source of friction. 37 00:01:58.400 --> 00:02:00.000 Yeah, that sounds painfully familiar. 38 00:02:00.079 --> 00:02:03.799 So Initially applications ran on physical servers, often those servers 39 00:02:03.799 --> 00:02:07.959 weren't even fully used. Then came virtual machines VMS. Big 40 00:02:08.000 --> 00:02:12.840 improvement VMS virtualized the hardware, letting you run multiple isolated 41 00:02:12.879 --> 00:02:16.560 operating systems on one physical box. But and this is 42 00:02:16.599 --> 00:02:19.560 a key thing, each VM still needed its own complete 43 00:02:19.560 --> 00:02:20.159 guest os. 44 00:02:20.280 --> 00:02:23.719 Okay, so lots of duplication, like extra baggage for every app. 45 00:02:23.759 --> 00:02:25.439 Precisely, think of it like having I don't know, a 46 00:02:25.479 --> 00:02:28.120 separate boiler room for every single apartment in a building. 47 00:02:28.280 --> 00:02:30.960 It works, but it's inefficient. Containers emerge as a much 48 00:02:31.000 --> 00:02:34.639 lighter alternative. Instead of virtualizing the hardware, they use operating 49 00:02:34.680 --> 00:02:38.199 system level virtualization. So a single host OS runs many 50 00:02:38.280 --> 00:02:42.319 isolated containers, and each container packages just the application itself 51 00:02:42.360 --> 00:02:45.560 and all its dependencies, the code, the run time tools, libraries, 52 00:02:45.840 --> 00:02:48.199 everything it needs, all bundled together, neat and tidy. 53 00:02:48.360 --> 00:02:51.599 Okay, So it's more like those apartments sharing the building's 54 00:02:51.599 --> 00:02:54.960 main boiler but each apartment is still totally self contained 55 00:02:55.000 --> 00:02:55.680 and isolated. 56 00:02:55.879 --> 00:02:58.400 That's a perfect analogy, And this leads to some really 57 00:02:58.439 --> 00:02:59.599 significant benefits. 58 00:02:59.840 --> 00:03:02.800 If I'm say a developer or leading a tech team. 59 00:03:03.240 --> 00:03:06.599 What's the real impact here beyond just saving server space, 60 00:03:07.000 --> 00:03:09.039 what's the deeper shift containers brought? 61 00:03:09.120 --> 00:03:11.759 Well, the big insight isn't just about packing things tighter, 62 00:03:11.879 --> 00:03:16.080 it's about killing that works on my machine problem. That consistency, 63 00:03:16.360 --> 00:03:21.319 the promise of build once run anywhere. It fundamentally changes 64 00:03:21.360 --> 00:03:24.240 the dynamic. It smooths out the whole process between developers 65 00:03:24.280 --> 00:03:27.840 writing code and operations running it. You get faster releases 66 00:03:27.879 --> 00:03:30.520 because everyone trusts that what worked in development will work 67 00:03:30.560 --> 00:03:33.199 in production. That confidence is huge, right. 68 00:03:33.120 --> 00:03:36.280 Less finger pointing, more shipping code's exactly. 69 00:03:35.879 --> 00:03:40.439 So you get consistency first and foremost predictable behavior everywhere. 70 00:03:40.479 --> 00:03:44.120 They're lightweight and efficient, much smaller than VM's start up 71 00:03:44.240 --> 00:03:47.240 way faster. You can run more apps on the same hardware, 72 00:03:47.280 --> 00:03:51.360 which saves money, real money. Isolation is key too. Apps 73 00:03:51.360 --> 00:03:54.599 don't interfere with each other or the host os, better security, 74 00:03:54.639 --> 00:03:58.599 fewer conflicts, portability, easy to move them around your laptop 75 00:03:58.680 --> 00:04:02.560 on prem servers, any cloud, and rapid creation and scaling. 76 00:04:02.759 --> 00:04:05.439 They start and stop in seconds. That's crucial for scaling 77 00:04:05.520 --> 00:04:07.879 quickly to meet demand, keeping things highly available. 78 00:04:08.240 --> 00:04:11.479 That consistency point really resonates having that single source of 79 00:04:11.520 --> 00:04:14.840 truth for the environment. Yeah wow, it sounds revolutionary for 80 00:04:14.879 --> 00:04:18.120 individual apps. Like you said, each plant in its perfect pot. 81 00:04:18.399 --> 00:04:20.959 But okay, what happens when your neat little garden turns 82 00:04:20.959 --> 00:04:23.680 into a massive commercial farm. When you've got hundreds of 83 00:04:23.720 --> 00:04:27.120 these containerized apps needing to work together, don't the benefits 84 00:04:27.120 --> 00:04:29.720 for one become a management nightmare for many. This is 85 00:04:29.759 --> 00:04:32.079 where things get really really interesting. I think once you 86 00:04:32.079 --> 00:04:35.959 start using containers seriously, especially for modern apps like micro services, yeah, 87 00:04:36.000 --> 00:04:38.079 you get a whole new set of problems. Right. Doing 88 00:04:38.120 --> 00:04:40.560 it manually just doesn't scale absolutely. 89 00:04:40.639 --> 00:04:43.920 Imagine that huge farm, hundreds of greenhouses. Now you need 90 00:04:43.920 --> 00:04:47.920 to ensure every greenhouse stays at the right temperature. If 91 00:04:47.920 --> 00:04:52.279 a plant dies, replace it immediately. If demand for tomato spikes, 92 00:04:52.360 --> 00:04:55.680 you need more tomato plants like now, some plants need 93 00:04:55.680 --> 00:04:59.000 to connect, maybe share nutrients, others must be kept totally separate. 94 00:04:59.240 --> 00:05:01.079 And you need a way to monitor the health of 95 00:05:01.240 --> 00:05:03.600 every single plant all the time. 96 00:05:03.759 --> 00:05:06.000 That's yeah, that's a lot. You can't just want around 97 00:05:06.120 --> 00:05:06.839 check in each one. 98 00:05:06.959 --> 00:05:09.879 No way. It grows exponentially, you'd need an army or, 99 00:05:10.000 --> 00:05:12.800 like you said earlier, a super smart automated system. 100 00:05:13.040 --> 00:05:15.639 So what is that automated system for containers. 101 00:05:16.079 --> 00:05:19.920 That's Kubernetes. It's the container orchestrator, developed originally by Google 102 00:05:20.000 --> 00:05:22.839 open source back in twenty fifteen and now managed by 103 00:05:22.839 --> 00:05:27.120 the CNCF, the Cloud Native Computing Foundation. Basically, Kubernetes automates 104 00:05:27.120 --> 00:05:29.720 the deployment, the ongoing management, and the scaling of all 105 00:05:29.720 --> 00:05:33.639 those containerized applications. It's built precisely to handle that complexity 106 00:05:33.680 --> 00:05:36.600 we just talked about, takes away the manual drudgery. 107 00:05:36.759 --> 00:05:39.720 Okay, So Kubernetes is the brain, the master control system 108 00:05:39.759 --> 00:05:42.519 for the container farm. How does it actually work? In 109 00:05:42.600 --> 00:05:44.480 simple terms, At its core. 110 00:05:44.560 --> 00:05:48.279 It groups your containers into logical units called pods. A 111 00:05:48.360 --> 00:05:51.639 pod is the smallest deployable thing. Think of it as 112 00:05:51.680 --> 00:05:55.120 that tiny greenhouse holding one or more closely related containers, 113 00:05:55.120 --> 00:05:58.920 maybe an app and its logging sidecar. These pods then 114 00:05:59.000 --> 00:06:01.800 run on nodes, which are your worker machines, the actual 115 00:06:01.839 --> 00:06:05.120 servers vms, your plots of land, and the whole show 116 00:06:05.240 --> 00:06:08.120 is run by the control plane. That's the brain. It 117 00:06:08.199 --> 00:06:11.639 manages the nodes and pods, handles things like self healing, 118 00:06:11.800 --> 00:06:17.319 restarting failed containers, automatically balancing incoming traffic, allocating resources efficiently 119 00:06:17.319 --> 00:06:18.759 across the whole cluster. 120 00:06:18.639 --> 00:06:21.920 Right setting up and managing that whole Kubernetes system, especially 121 00:06:21.959 --> 00:06:26.519 that control plane. That sounds like a massive job in itself. Powerful, yes, 122 00:06:26.639 --> 00:06:28.480 but maybe too complex if you just want to run 123 00:06:28.480 --> 00:06:31.240 your apps. Is there an easier way, a shortcut? 124 00:06:31.360 --> 00:06:34.279 Absolutely, And that's exactly where managed Kubernetes services come in. 125 00:06:34.319 --> 00:06:36.920 The prime example we're talking about today is Azure Kubernetes 126 00:06:36.920 --> 00:06:41.160 Service AKS. With AKS, Microsoft, Azure handles the creation, the operation, 127 00:06:41.319 --> 00:06:44.600 the scaling, the patching, all the really complex bits of 128 00:06:44.639 --> 00:06:47.600 the control plane infrastructure for you. They abstract it away. 129 00:06:47.680 --> 00:06:50.160 Okay, So Azure manages the brain the hard part. 130 00:06:50.639 --> 00:06:54.480 Essentially, Yes, you get the power of Kubernetes orchestration without 131 00:06:54.519 --> 00:06:57.000 needing a dedicated team just to keep the orchestrator itself 132 00:06:57.079 --> 00:06:57.839 running smoothly. 133 00:06:58.399 --> 00:07:00.879 So if I choose AKS, what do I need to 134 00:07:00.879 --> 00:07:04.040 focus on? What's my job versus Azure's job, and what's 135 00:07:04.079 --> 00:07:05.560 the real strategic payoff? 136 00:07:05.680 --> 00:07:09.680 You focus on your applications, building them, containerizing them, deploying them. 137 00:07:09.920 --> 00:07:13.720 You focus on your plants, your unique value. AKAS takes 138 00:07:13.720 --> 00:07:16.839 care of provisioning the nodes, the land and ensures that 139 00:07:16.879 --> 00:07:21.480 control plane is always available, reliable handling, scaling, handling failures. 140 00:07:21.879 --> 00:07:24.319 It's a true platform as a service, a pair cause 141 00:07:24.560 --> 00:07:28.120 but specifically for Kubernetes, lets you move faster, move faster. 142 00:07:28.240 --> 00:07:30.639 Yeah, that's always good. What are the specific benefits? 143 00:07:30.800 --> 00:07:34.000 Well, first, reduced infrastructure overhead. You can spin up an 144 00:07:33.959 --> 00:07:37.319 AKAS cluster in minutes, not days or weeks. Your engineers 145 00:07:37.319 --> 00:07:40.360 aren't wrestling with Kubernetes set up, they're building features. It 146 00:07:40.439 --> 00:07:41.600 frees up your best people. 147 00:07:41.759 --> 00:07:45.560 That's huge, less time on plumbing, more on innovation exactly. 148 00:07:46.319 --> 00:07:50.120 Then there's enhanced operational efficiency. Monitoring is easier, you get 149 00:07:50.160 --> 00:07:53.560 optimization tips to measure, Advisor node management is simpler, upgrades 150 00:07:53.600 --> 00:07:56.680 are smoother. Your farm just runs better with less effort. 151 00:07:57.399 --> 00:08:02.079 Flexibility is another big one. Run almost anything dot Net, Java, Python, 152 00:08:02.279 --> 00:08:06.399 NOJS in Linux containers or Windows containers. That opens up 153 00:08:06.439 --> 00:08:10.560 modernization paths for lots of different apps, rapid development and deployment. 154 00:08:10.800 --> 00:08:14.240 It plugs right into things like Azure debops for CICD pipelines, 155 00:08:14.279 --> 00:08:18.319 infrastructure as code tools, makes automation much easier, and crucially 156 00:08:18.439 --> 00:08:22.720 enterprise grade security integration with Azure Active Directory for access control, 157 00:08:22.920 --> 00:08:26.600 threat detection with Azur Security Center, network isolation options like 158 00:08:26.600 --> 00:08:30.439 Azure Private Link applying security policies. It's built with security 159 00:08:30.439 --> 00:08:30.800 in mind. 160 00:08:30.879 --> 00:08:34.600 Okay, that reduced overhead and faster innovation cycle sounds incredibly compelling. 161 00:08:34.840 --> 00:08:37.039 But let me play Devil's advocate for a second. By 162 00:08:37.159 --> 00:08:40.480 letting Azure manage the control plane, do I lose critical control? 163 00:08:40.799 --> 00:08:42.840 Is there a downside of trade off compared to running 164 00:08:42.840 --> 00:08:44.559 my own Kubernetes cluster from scratch. 165 00:08:44.679 --> 00:08:47.440 That's a really important question, and yes there's a trade off. 166 00:08:47.879 --> 00:08:51.759 With a fully self managed Kubernetes setup, you control everything, 167 00:08:52.120 --> 00:08:55.240 the OS on the master nodes, the exact component versions, 168 00:08:55.360 --> 00:08:59.799 every single knob. But that control comes with immense responsibility. 169 00:09:00.039 --> 00:09:02.080 You have to patch it, upgrade it, secure it, and 170 00:09:02.120 --> 00:09:06.080 sure it's highly available yourself. That needs dedicated expertise a 171 00:09:06.120 --> 00:09:10.159 specialized team. It's a significant operational burden. 172 00:09:09.879 --> 00:09:11.639 Right You're on the whole stack, warts and all. 173 00:09:11.639 --> 00:09:15.159 Exactly with Akas. You trade some of that deep infrastructure 174 00:09:15.240 --> 00:09:19.399 level control for operational simplicity and reliability. Azure handles the 175 00:09:19.399 --> 00:09:25.000 control planes, health, patching availability. For most organizations, especially those 176 00:09:25.000 --> 00:09:28.639 whose core business isn't runn Kubernetes infrastructure, that trade off 177 00:09:28.679 --> 00:09:33.039 is incredibly worthwhile. The speed the reduced burden leveraging azures 178 00:09:33.039 --> 00:09:36.480 built in security and monitoring it usually far outweighs the 179 00:09:36.480 --> 00:09:39.240 slight loss of granular control. You focus on your apps, 180 00:09:39.240 --> 00:09:40.440 not the orchestrator's clumbing. 181 00:09:40.639 --> 00:09:43.320 That makes total sense. It's like choosing whether to build 182 00:09:43.360 --> 00:09:46.120 your own house from the foundation up or buying a 183 00:09:46.200 --> 00:09:49.639 well managed condo where the building maintenance is handled. Both work, 184 00:09:50.240 --> 00:09:52.919 but one lets you focus on decorating your living room faster. 185 00:09:53.879 --> 00:09:57.840 So okay, we've chosen akas our managed farm. Now we're inside. 186 00:09:58.279 --> 00:10:00.879 What are the essential bits we need to grasp to 187 00:10:00.919 --> 00:10:04.240 actually get our applications running well? How do things like 188 00:10:04.320 --> 00:10:07.879 networking work within AKS? Let's get into those core concepts. 189 00:10:08.000 --> 00:10:10.279 All right, let's break down the key components inside your 190 00:10:10.279 --> 00:10:14.399 AKS cluster. First up, networking your apps. Your pods need 191 00:10:14.440 --> 00:10:17.679 to talk for internal communications securely within the cluster. You 192 00:10:17.759 --> 00:10:20.840 use cluster ip. Think of it as an internal phone line. 193 00:10:20.960 --> 00:10:23.399 Pods can reach each other, but nothing outside can directly 194 00:10:23.440 --> 00:10:23.840 call in. 195 00:10:24.000 --> 00:10:27.519 Okay, private communication. What about reaching the outside world or 196 00:10:27.600 --> 00:10:29.399 letting users reach my app? Right? 197 00:10:29.759 --> 00:10:32.919 For external access, You've got a few options. Nodeport is 198 00:10:32.960 --> 00:10:35.919 a symbol way exposing your service on a specific port 199 00:10:36.000 --> 00:10:39.279 on each node, but more commonly you'll use a load balancer. 200 00:10:39.840 --> 00:10:43.440 This distributes incoming traffic across multiple pods running your service, 201 00:10:43.799 --> 00:10:46.759 usually on standard ports like eighty or four forty three. 202 00:10:47.080 --> 00:10:50.000 It's like having a receptionist directing visitors to the right office, 203 00:10:50.039 --> 00:10:52.200 making sure no single office gets overloaded. 204 00:10:52.399 --> 00:10:55.799 And you mentioned something more sophisticated, like directing traffic based 205 00:10:55.840 --> 00:10:56.679 on the URL. 206 00:10:56.840 --> 00:10:59.879 Yeah, for that more intelligent roading. Maybe setting a pyrate 207 00:11:00.000 --> 00:11:02.679 request to one set of pods and web requests to another. 208 00:11:02.840 --> 00:11:05.080 You use an ingress controller. Think of it as a 209 00:11:05.120 --> 00:11:08.200 smart mail sorter, looking at the address, the URL path 210 00:11:08.279 --> 00:11:11.559 or host name to route traffic precisely where it needs 211 00:11:11.600 --> 00:11:15.440 to go. Common ones are NGI, NX ingress or Azure's 212 00:11:15.480 --> 00:11:17.320 own application gateway ingress. 213 00:11:17.039 --> 00:11:20.399 Controller That mail sorter analogy helps. Okay, so that's traffic 214 00:11:20.440 --> 00:11:22.240 in and around the cluster. What about how the cluster 215 00:11:22.320 --> 00:11:25.159 itself plugs into the bigger Azure network. Does that choice 216 00:11:25.159 --> 00:11:25.799 matter much? 217 00:11:25.919 --> 00:11:28.639 It matters quite a bit. Actually, When you set up AKS, 218 00:11:28.679 --> 00:11:32.039 you pick a networking model. The simpler one is basic 219 00:11:32.080 --> 00:11:37.279 networking kubinet. Here AKS manages a virtual network largely behind 220 00:11:37.279 --> 00:11:40.720 the scenes, and pods get ips from a separate address space. 221 00:11:41.000 --> 00:11:42.039 It's easier to start with. 222 00:11:42.080 --> 00:11:43.879 Okay, simple start. What's the alternative? 223 00:11:44.159 --> 00:11:48.639 The alternative is advanced networking. As your CNI CNI stands 224 00:11:48.679 --> 00:11:52.720 for Container Networking Interface. With this, your pods get IP 225 00:11:52.840 --> 00:11:55.919 addresses directly from your own Azure virtual network, the same 226 00:11:56.000 --> 00:11:59.279 VNA your other Azure resources might be in. This gives 227 00:11:59.320 --> 00:12:02.159 you much more controls. You can apply network policies directly 228 00:12:02.200 --> 00:12:06.000 to pods, integrate tightly with firewalls, and allow direct communication 229 00:12:06.080 --> 00:12:09.080 between pods and other v net resources. It's usually the 230 00:12:09.159 --> 00:12:11.879 way to go for enterprise setups or anything needing complex 231 00:12:11.919 --> 00:12:12.559 network rules. 232 00:12:12.600 --> 00:12:16.200 Got it basic for ease, advance for control and integration. Okay, 233 00:12:16.240 --> 00:12:20.799 next challenge, not data containers disappear, pods can be replaced. 234 00:12:21.240 --> 00:12:23.279 How do we handle storage for apps that need to 235 00:12:23.360 --> 00:12:25.840 keep their data like a database running in a container. 236 00:12:26.159 --> 00:12:29.799 Yeah, that's critical. Containers are ephemeral. Like you said, AKS 237 00:12:29.799 --> 00:12:33.039 provides volumes for temporary data within a POD's life, things 238 00:12:33.080 --> 00:12:36.840 like scratch space, empty dur or mountain configuration can figmap 239 00:12:37.360 --> 00:12:41.279 and secrets secret. But if the pod dies, that data 240 00:12:41.399 --> 00:12:42.000 is gone. 241 00:12:42.080 --> 00:12:45.279 So we need something durable, like an external hard drive exactly. 242 00:12:45.639 --> 00:12:48.279 For data that needs to survive pod restarts or moves, 243 00:12:48.320 --> 00:12:53.080 you use persistent volumes pvs. These represent actual storage resources 244 00:12:53.080 --> 00:12:56.519 outside the pod. Typically they map to Azure manage discs, 245 00:12:56.639 --> 00:12:59.840 Azure disks for storage needed by a single POD, or 246 00:13:00.120 --> 00:13:03.440 shared file storage Azure files if multiple pods need to 247 00:13:03.480 --> 00:13:05.120 access the same data concurrently. 248 00:13:05.320 --> 00:13:08.240 Okay, so pvs are the durable storage. How do my 249 00:13:08.279 --> 00:13:10.559 applications actually request the storage they need? 250 00:13:10.799 --> 00:13:14.639 They do that using persistent volume claims PVCs. Think of 251 00:13:14.639 --> 00:13:17.600 a PVC as a request the POD says I need 252 00:13:17.639 --> 00:13:21.440 fifty gigabytes of standard disk storage. Kubernetes then tries to 253 00:13:21.480 --> 00:13:24.440 match that request to an available PV and to make 254 00:13:24.480 --> 00:13:27.600 this dynamic and defined types of storage available, we use 255 00:13:27.759 --> 00:13:31.000 storage classes. A storage class defines what kind of Azure 256 00:13:31.000 --> 00:13:34.960 storage backs the PV like standard HDD, Premium SSD, or 257 00:13:35.000 --> 00:13:38.639 Azure files, and its reclamation policy. So the flow is 258 00:13:38.879 --> 00:13:42.320 admin defined storage classes types of storage. POD request storage 259 00:13:42.360 --> 00:13:46.320 via PVC. Kubernetes dynamically provisions a PV based on a 260 00:13:46.399 --> 00:13:48.600 matching storage class and binds it to the PVC for 261 00:13:48.639 --> 00:13:50.679 the POD to use. It's a neat, automated way to 262 00:13:50.679 --> 00:13:52.440 manage persistent data right a. 263 00:13:52.360 --> 00:13:56.759 Structured request system. Storage classes define the catalog PVCs are 264 00:13:56.799 --> 00:14:02.159 the order forms. Makes sense? Okay. Shifting to another crucial topic, scaling, 265 00:14:02.399 --> 00:14:04.679 We know aks helps us scaling, But how exactly? What 266 00:14:04.720 --> 00:14:07.200 are the main mechanisms for handling more load? And what 267 00:14:07.240 --> 00:14:09.080 about those sudden, unpredictable bursts. 268 00:14:09.240 --> 00:14:12.360 Great question. AKS offers several ways to handle scaling. You 269 00:14:12.360 --> 00:14:14.279 can always do manual scaling. Just go in and change 270 00:14:14.279 --> 00:14:16.759 the number of pods or nodes yourself. Simple but reactive. 271 00:14:17.039 --> 00:14:19.399 Right, you have to guess or wait until things break. 272 00:14:19.639 --> 00:14:20.200 Not ideal. 273 00:14:20.360 --> 00:14:23.519 Not ideal for dynamic loads, no, So that's where automatic 274 00:14:23.519 --> 00:14:27.000 scaling comes in. There are two main types working together. First, 275 00:14:27.039 --> 00:14:30.679 the cluster autoscaler. This watches for pods that can't be 276 00:14:30.720 --> 00:14:34.240 scheduled because there are enough resources CPU memory on the 277 00:14:34.279 --> 00:14:37.879 existing nodes. If it sees that, it automatically adds more 278 00:14:39.000 --> 00:14:42.559 land to your cluster. It scales the infrastructure. 279 00:14:41.879 --> 00:14:44.440 Okay, as more servers if needed. What about scaling the 280 00:14:44.480 --> 00:14:45.919 apps themselves, That's. 281 00:14:45.720 --> 00:14:49.840 The job of the horizontal pod autoscaler HPA. The HPA 282 00:14:49.960 --> 00:14:54.039 monitors metrics like CP utilization or memory usage for your pods. 283 00:14:54.519 --> 00:14:57.759 If the average CPU goes above say seventy percent, the 284 00:14:57.960 --> 00:15:01.919 HPA automatically increases the number of pod replicas pods for 285 00:15:01.960 --> 00:15:04.519 that application. When load drops, it scales back down. 286 00:15:04.600 --> 00:15:07.799 So cluster autoscaler ADS nodes, HPA ADS pods. They work 287 00:15:07.840 --> 00:15:08.799 together precisely. 288 00:15:08.960 --> 00:15:12.759 HbA needs resources, cluster atoscaler provides them if necessary. 289 00:15:12.320 --> 00:15:16.240 But adding a whole new node a VM can take minutes. 290 00:15:16.320 --> 00:15:18.759 What if I get a massive instant spike in traffic 291 00:15:19.000 --> 00:15:22.519 like viral marketing campaign level spike? Is there anything faster? Yes? 292 00:15:22.799 --> 00:15:24.840 And this is a really powerful feature for that kind 293 00:15:24.840 --> 00:15:29.200 of brust scenario. It involves using serverless nodes which leverage 294 00:15:29.240 --> 00:15:33.759 Azure Container instances ACI through something called virtual Cublet. Virtual 295 00:15:33.840 --> 00:15:39.039 cublet lets AKS schedule pods onto ACI. ACI provisions containers 296 00:15:39.039 --> 00:15:42.399 in seconds, way faster than spinning up a full VM node. 297 00:15:42.720 --> 00:15:46.159 So for sudden burths, AKS can instantly schedule extra pods 298 00:15:46.200 --> 00:15:48.080 onto ACI via virtual cublt. 299 00:15:48.120 --> 00:15:50.720 Wow seconds versus minutes. That's a huge difference when you're 300 00:15:50.759 --> 00:15:51.399 under heavy load. 301 00:15:51.480 --> 00:15:53.519 It really is. We actually use this during a big launch. 302 00:15:53.559 --> 00:15:56.360 We had an unexpected flood of traffic from social media. 303 00:15:56.600 --> 00:15:59.960 Virtual cubult just kicked in scaled up pods onto ACI 304 00:16:00.039 --> 00:16:03.320 almost instantly handle the bursts without a hitch. If we'd 305 00:16:03.399 --> 00:16:06.480 relied only on traditional node scaling, we might have had issues. 306 00:16:06.720 --> 00:16:09.679 That's a brilliant real world save, so you only pay 307 00:16:09.679 --> 00:16:13.080 for ACI when it's actually running those burst pods exactly. 308 00:16:13.159 --> 00:16:15.879 You pay for the execution time. It provides that rapid 309 00:16:15.879 --> 00:16:20.759 elasticity without paying for idle capacity. And this serverless event 310 00:16:20.840 --> 00:16:24.279 driven scaling concept is also how you run things like 311 00:16:24.559 --> 00:16:29.039 containerized Azure functions on AKS using kDa Kubernetes event driven 312 00:16:29.080 --> 00:16:32.279 auto scaling KATA can scale your function pods down to 313 00:16:32.399 --> 00:16:35.159 zero when idle, and then scale them out rapidly based 314 00:16:35.200 --> 00:16:38.440 on event triggers like QUEU messages or Coughka topics, super 315 00:16:38.440 --> 00:16:39.960 cost effective for certain workloads. 316 00:16:40.080 --> 00:16:44.960 Okay, that's incredibly flexible scaling. So we've got networking storage scaling. 317 00:16:45.279 --> 00:16:48.159 How do we actually tell Kubernetes how we want our 318 00:16:48.159 --> 00:16:50.960 applications managed? What are the different ways we can instruct 319 00:16:50.960 --> 00:16:52.200 it the deployment patterns. 320 00:16:52.320 --> 00:16:56.279 We communicate our intentions to Kubernetes using declarative configuration files, 321 00:16:56.360 --> 00:16:59.480 usually written in Yamel. These manifests describe the desired state, 322 00:16:59.519 --> 00:17:02.480 will contain on how many replicas, network settings, et cetera. 323 00:17:02.879 --> 00:17:06.000 Kubernetes then works constantly to make the actual state match 324 00:17:06.039 --> 00:17:06.960 that desired state. 325 00:17:07.559 --> 00:17:09.720 So yamal files are the blueprints. What are the common 326 00:17:09.720 --> 00:17:11.160 types of blueprints or patterns. 327 00:17:11.319 --> 00:17:14.759 Well. For typical stateless applications like web front ends or 328 00:17:14.799 --> 00:17:18.039 APIs where each request is independent, the most common pattern 329 00:17:18.079 --> 00:17:21.519 is using deployments which manage replica sets underneath. A replica 330 00:17:21.519 --> 00:17:24.400 set simply ensures that a specified number of identical pod 331 00:17:24.440 --> 00:17:27.960 replicas are always running. If a pod dies, the replica 332 00:17:27.960 --> 00:17:31.039 set controller notices and creates a new one. It provides 333 00:17:31.200 --> 00:17:34.359 basic high availability and scaling for stateless apps. 334 00:17:34.599 --> 00:17:38.839 Think interchangeable workers exand standard pattern for stateless stuff. What 335 00:17:38.880 --> 00:17:41.759 about apps that do have state or need special handling 336 00:17:42.480 --> 00:17:43.559 like databases. 337 00:17:43.880 --> 00:17:47.599 Right for applications that need stable unique identities or persistent 338 00:17:47.640 --> 00:17:51.279 storage tied to each instance like databases, message queues, or 339 00:17:51.319 --> 00:17:54.079 anything with a leader follower setup, you use stateful sets. 340 00:17:54.359 --> 00:17:57.839 Stateful sets provide guarantees about the ordering and uniqueness of pods. 341 00:17:58.079 --> 00:18:00.799 Each pod gets a stable network identical fire like dB 342 00:18:00.960 --> 00:18:04.039 zero dB one, and its own persistent storage volume that 343 00:18:04.079 --> 00:18:06.519 follows it, even if the pod gets rescheduled to a 344 00:18:06.519 --> 00:18:09.519 different node. It's crucial for apps where identity and data 345 00:18:09.559 --> 00:18:11.200 persistence per instance. 346 00:18:10.960 --> 00:18:14.079 Matter, So predictable names and storage for stateful apps. Got it? 347 00:18:14.400 --> 00:18:15.920 Any other key patterns. 348 00:18:15.640 --> 00:18:17.960 The other main one is the demon set. A demon 349 00:18:18.039 --> 00:18:21.200 set ensures that a copy of a specific pod runs 350 00:18:21.240 --> 00:18:24.000 on all nodes in the cluster or on a specific 351 00:18:24.079 --> 00:18:27.319 subset of nodes you define. This is typically used for 352 00:18:27.400 --> 00:18:30.440 cluster level agents or services that need to be present everywhere. 353 00:18:30.559 --> 00:18:35.400 Think logging collectors, monitoring agents, node problem detectors. They're like 354 00:18:35.480 --> 00:18:37.920 the essential maintenance true that needs to be on every 355 00:18:37.960 --> 00:18:38.599 part of the farm. 356 00:18:38.880 --> 00:18:42.599 Okay, replica sets for stateless, stateful sets for stateful, demon 357 00:18:42.680 --> 00:18:46.519 sets for everywhere. That covers the main ways to deploy. 358 00:18:46.720 --> 00:18:50.119 So we've got our apps running, scaled, managed using these patterns. 359 00:18:50.160 --> 00:18:53.319 We're feeling pretty good. But what about day to day reality? 360 00:18:53.319 --> 00:18:56.680 How do we operationalize this integrated into our development workflows, 361 00:18:56.759 --> 00:18:58.920 keep it healthy? What else do we need to truly 362 00:18:59.000 --> 00:18:59.880 master akas? 363 00:19:00.160 --> 00:19:04.400 That's the crucial next step operationalizing it first. Devups integration 364 00:19:04.720 --> 00:19:08.160 automation is absolutely key. You really want to leverage Azure 365 00:19:08.200 --> 00:19:11.480 devups pipelines or similar tools for CICD, continuous integration and 366 00:19:11.519 --> 00:19:14.920 continuous delivery. These pipelines automate the whole flow, building your 367 00:19:14.920 --> 00:19:18.759 application code, creating the container image, pushing that image to 368 00:19:18.839 --> 00:19:22.319 a secure private registry like Azure Container Registry ACR. 369 00:19:22.519 --> 00:19:25.359 ACR is like our private library for container images. 370 00:19:25.079 --> 00:19:29.000 Right exactly your secure private Docker registry and Azure. Then 371 00:19:29.039 --> 00:19:32.640 the pipeline continues deploying your application to aks, usually by 372 00:19:32.680 --> 00:19:36.079 applying those yamal manifests or using helm charts, which are 373 00:19:36.119 --> 00:19:40.640 like packages of Kubernetes resources. Automating this saves massive amounts 374 00:19:40.640 --> 00:19:44.400 of manual effort, reduces errors, speeds up releases dramatically, and 375 00:19:44.480 --> 00:19:48.480 lets you embed quality gates like automated testing right into 376 00:19:48.480 --> 00:19:51.640 the process. It's the automated assembly line makes sense. 377 00:19:51.839 --> 00:19:54.960 Automation is critical. Now once it's deployed and running, how 378 00:19:54.960 --> 00:19:58.480 do we keep tabs on it? Monitor performance, troubleshoot problems 379 00:19:58.519 --> 00:19:59.759 when they inevitably happen. 380 00:20:00.000 --> 00:20:03.240 If for monitoring and troubleshooting, the primary tool and Azure 381 00:20:03.400 --> 00:20:06.720 is Azure Monitor for containers. It gives you really deep 382 00:20:06.839 --> 00:20:11.079 visibility into your cluster. It collects performance metrics, CPU memory 383 00:20:11.160 --> 00:20:15.799 usage for nodes, pods, individual containers. It also collects logs 384 00:20:15.839 --> 00:20:18.480 from your containers. All this data gets sent to a 385 00:20:18.519 --> 00:20:21.880 log analytics workspace where you can query it, visualize it, 386 00:20:21.960 --> 00:20:25.480 create dashboards. You can view container logs in real time. 387 00:20:25.759 --> 00:20:28.519 Set up alerts based on metrics or log entries like 388 00:20:28.799 --> 00:20:31.559 alert me if CPU usage stays above ninety percent for 389 00:20:31.640 --> 00:20:34.559 five minutes, or alert if we see error messages in 390 00:20:34.599 --> 00:20:35.160 the logs? 391 00:20:36.079 --> 00:20:38.400 Can you also see what the Kubernety system itself is 392 00:20:38.480 --> 00:20:40.400 doing like the control plane logs. 393 00:20:40.640 --> 00:20:43.480 Yes, you can configure AKS to send control plane logs 394 00:20:43.519 --> 00:20:46.440 things like the Cube appaserver logs which show API requests, 395 00:20:46.759 --> 00:20:49.599 or the scheduler logs to log analytics as well. Same 396 00:20:49.640 --> 00:20:51.880 for node level logs like the Cube lit This is 397 00:20:51.920 --> 00:20:55.119 invaluable for diagnosing deeper cluster issues. It's your central dashboard 398 00:20:55.160 --> 00:20:58.920 investigation toolkit. And one more operational aspect worth mentioning specifically 399 00:20:59.039 --> 00:21:00.920 is Windows containers on As. 400 00:21:01.079 --> 00:21:02.640 You mentioned that flexibility earlier. 401 00:21:02.720 --> 00:21:06.319