WEBVTT 00:00.080 --> 00:05.780 In this video, you will understand why Kubernetes dominated the cloud and how it quickly became the 00:05.780 --> 00:10.010 de facto standard tool for managing cloud native applications. 00:10.130 --> 00:17.480 In 2015, the term cloud native started getting really popular because it emphasizes applications designed 00:17.480 --> 00:19.700 specifically for cloud environments. 00:19.730 --> 00:26.540 A cloud native app is one that's distributed into many applications called microservices. 00:26.540 --> 00:32.370 You don't want your app to be this one big, chunky and clunky, hard to update monolith. 00:32.370 --> 00:39.510 Instead, you want to split it into many microservices, where each one performs a specific task and 00:39.510 --> 00:41.160 runs inside of a container. 00:41.160 --> 00:48.930 Ideally, a container is a lightweight environment that isolates your application by ensuring that it 00:48.930 --> 00:53.250 only runs with the resources and dependencies that it needs. 00:53.250 --> 00:58.660 This containerization allows your app to run reliably anywhere, whether that's your laptop or some 00:58.660 --> 01:03.880 cloud provider, which is what makes containerized microservices truly cloud native. 01:03.880 --> 01:09.970 Their ability to run reliably anywhere across different environments, on top of the fact that they're 01:09.970 --> 01:15.550 ideal for the clouds is need to scale very quickly and deploy very fast. 01:15.550 --> 01:18.730 Now, the microservice architecture isn't perfect. 01:18.730 --> 01:24.310 Every benefit comes with a drawback in the sense that the more microservices you have, they become 01:24.310 --> 01:25.600 harder to manage. 01:25.630 --> 01:28.720 Think about things like resource allocation. 01:28.720 --> 01:34.180 How do you efficiently distribute memory and CPU across numerous microservices? 01:34.180 --> 01:37.480 That requires a lot of manual orchestration. 01:37.600 --> 01:39.340 Think about resiliency. 01:39.340 --> 01:45.650 When a service becomes unresponsive for whatever reason, what mechanisms can we employ to ensure that 01:45.650 --> 01:51.080 the container is automatically resurrected and restarted back to a healthy state? 01:51.320 --> 01:53.870 Think about things like load balancing. 01:53.870 --> 01:58.790 If an app is getting lots of traffic, it can eventually run out of memory or CPU. 01:58.820 --> 02:06.560 How do you dynamically scale up instances of that microservice and balance the load to ensure that traffic 02:06.560 --> 02:11.040 is distributed equally among all your application instances. 02:11.040 --> 02:16.800 These are just a few of the many considerations that you need to be mindful of when managing containers, 02:16.800 --> 02:20.010 because deploying containers is just the beginning. 02:20.010 --> 02:20.910 Anybody can do that. 02:20.910 --> 02:22.440 That's the easy part. 02:22.470 --> 02:30.180 The real challenge and expertise lies in efficiently managing and orchestrating your containers at scale. 02:30.180 --> 02:36.610 Well, let's go back to 2014 when an engineer from Google revealed that they were releasing 2 billion 02:36.610 --> 02:37.810 containers a year. 02:37.810 --> 02:44.830 They had their own in-house container orchestration tool called Borg that dealt with all of these problems 02:44.830 --> 02:51.670 and automated things like scaling, resiliency, resource orchestration, load balancing, among many 02:51.670 --> 02:52.450 other features. 02:52.450 --> 02:59.680 And based on their success with Borg, Google open sourced the container orchestration platform Kubernetes 02:59.680 --> 03:01.120 that same year. 03:01.570 --> 03:07.720 And because of Google's credibility, um, Kubernetes is now the de facto standard tool for container 03:07.720 --> 03:08.440 orchestration. 03:08.440 --> 03:12.730 So let's assume you have Kubernetes hosted on AWS, Azure or Google Cloud. 03:12.730 --> 03:18.850 Then Kubernetes can be described as a software that runs across many virtual machines. 03:18.940 --> 03:24.590 If you have Kubernetes hosted on your own servers on premise, which is typical to government agencies 03:24.590 --> 03:31.340 that require more security than Kubernetes, can be described as a software that runs across many physical 03:31.340 --> 03:31.970 servers. 03:32.000 --> 03:38.240 Now, regardless, these machines in the world of Kubernetes we refer to as nodes. 03:38.240 --> 03:42.500 And these nodes, these machines, they collaborate. 03:42.500 --> 03:49.350 They work together under the supervision of Kubernetes to manage your container workloads. 03:49.350 --> 03:55.920 They come together to form a unified Kubernetes cluster that can orchestrate your containers at scale. 03:55.920 --> 04:01.740 So in a Kubernetes cluster, some machines are designated as master nodes, forming the brains of the 04:01.740 --> 04:07.860 operation, while the other machines, the other nodes are worker nodes, the master nodes. 04:07.860 --> 04:14.890 They make decisions about when and where your container workloads will run, while the worker nodes, 04:14.890 --> 04:18.670 they have the infrastructure to actually run your container workloads. 04:18.670 --> 04:20.140 Let me dive a bit deeper. 04:20.290 --> 04:27.640 So the pod in Kubernetes is the smallest deployable unit, meaning you can't deploy containers directly. 04:27.640 --> 04:30.040 They must be wrapped in a pod. 04:30.460 --> 04:36.260 Now, to deploy an application, I can simply specify a configuration that declares what my container 04:36.260 --> 04:42.740 will be called and the image a prebuilt package of my application, source code and dependencies from 04:42.740 --> 04:47.360 which the container will be created, and the resources that the application needs in order to run like 04:47.360 --> 04:53.630 the CPU and memory, I simply have to declare this configuration, and upon submitting it to the cluster, 04:53.630 --> 04:56.960 the Kubernetes control plane just springs into action. 04:59.960 --> 05:05.660 But ultimately, what I wanted to convey is not necessarily what's going on behind the scenes, but 05:05.660 --> 05:08.990 show you that this process really illustrates. 05:08.990 --> 05:11.210 Kubernetes is declarative nature. 05:11.240 --> 05:14.510 We simply declare, we simply state what we want. 05:14.510 --> 05:20.090 And behind the scenes, there are so many moving parts where Kubernetes manages the complex details 05:20.090 --> 05:23.270 of deployment, resource allocation, and maintenance. 05:23.270 --> 05:27.930 It also goes further in orchestrating the discovery of these services. 05:28.080 --> 05:35.160 Every pod has a virtual IP address by which it can be accessed, by which it can be connected to. 05:35.280 --> 05:42.390 But pods in Kubernetes are ephemeral, which means they, um, they get destroyed or recreated very 05:42.390 --> 05:43.140 often. 05:43.320 --> 05:49.690 That's why Kubernetes offers a primitive called a service that specifically binds to pods with a certain 05:49.690 --> 05:57.730 label like great submission, and regardless of their individual IP address, all great submission pods. 05:57.730 --> 06:04.420 They share this label, which effectively allows the service to consistently route traffic to them. 06:04.630 --> 06:09.970 And not only do services in Kubernetes make it really easy to connect to our applications, they also 06:09.970 --> 06:16.820 act as natural load balancers if multiple instances of the Great Submission app are running simultaneously, 06:16.820 --> 06:23.300 the service will evenly distribute incoming traffic among them, and this ensures that the load is balanced 06:23.300 --> 06:25.670 across all available pods. 06:26.570 --> 06:32.990 Okay, and now one of the most powerful features that Kubernetes provides is storage orchestration. 06:32.990 --> 06:37.580 Manually provisioning storage for your databases is really, really hard work. 06:37.610 --> 06:39.740 Kubernetes automates that for you. 06:39.770 --> 06:45.470 For each database instance, Kubernetes allows you to define your storage requirements in a persistent 06:45.470 --> 06:46.640 volume claim. 06:46.760 --> 06:53.330 When the Kubernetes control plane behind the scenes sees your persistent volume claim your PVC, it 06:53.330 --> 06:58.490 takes on the burden of looking through all of the nodes in your cluster, every machine in your cluster, 06:58.490 --> 07:04.560 and within one of them, Kubernetes will try to find a physical piece of storage and create a persistent 07:04.560 --> 07:06.540 volume linked to your claim. 07:06.540 --> 07:13.020 This allows any data that gets saved to your MongoDB database to be redirected to a persistent volume, 07:13.020 --> 07:17.340 to a durable piece of storage that lives inside of some node. 07:17.490 --> 07:23.400 And what's really powerful here is that it doesn't matter where your Kubernetes cluster is deployed, 07:23.400 --> 07:30.280 be it AWS, Azure, or Google Cloud, Kubernetes abstracts away the underlying infrastructure. 07:30.280 --> 07:36.490 It itself is going to take on the burden of scanning every node for that piece of storage and provision 07:36.490 --> 07:38.890 it for the container that needs it. 07:38.890 --> 07:44.260 Now, speaking of platform is one of Kubernetes biggest selling points is the fact that it's vendor 07:44.260 --> 07:46.360 neutral and it works the same way. 07:46.360 --> 07:52.010 Regardless of whether your cluster is deployed on AWS, Azure, Google Cloud or on premises. 07:52.010 --> 07:57.200 Kubernetes abstracts away the underlying infrastructure, which means you can define your applications 07:57.200 --> 08:01.940 as configuration once and deploy them anywhere Kubernetes runs. 08:01.940 --> 08:04.910 In other words, no more vendor lock in. 08:04.910 --> 08:11.600 I want to finalize this video by emphasizing that deploying your application on a Kubernetes cluster. 08:12.260 --> 08:18.800 It automates very powerful mechanisms that are needed to manage and orchestrate the life cycle of your 08:18.800 --> 08:20.420 containers at scale. 08:20.480 --> 08:25.340 Kubernetes handles things like service discovery, load balancing, resource management, storage, 08:25.340 --> 08:30.710 orchestration, as you just saw, and many, many other complex tasks that are challenging to implement 08:30.710 --> 08:31.430 on your own. 08:31.430 --> 08:35.390 So by abstracting away all of these intricacies, Kubernetes. 08:35.390 --> 08:42.510 Kubernetes lets you focus on just developing your cloud native app while it takes on the burden, while 08:42.510 --> 08:45.450 it takes care of the operational heavy lifting. 08:45.450 --> 08:52.890 That is why Kubernetes dominated the cloud and became the de facto standard for managing cloud native 08:52.890 --> 08:56.970 applications across virtually every major platform. 08:57.000 --> 08:58.500 I hope you enjoyed this video. 08:58.500 --> 09:04.110 Make sure to do the upcoming quiz to really solidify the concepts that were discussed in this lesson, 09:04.110 --> 09:05.280 and I will see you there.