网络课程笔记

00:00 Hello,

00:01 and let's first see the Kubernetes architecture,

00:04 and here we are going to talk about Kubernetes open source.

00:07 Now, at this moment,

00:09 I hope that you already know what are containers,

00:11 what are microservices, and why Kubernetes.

00:14 But if not, I recommend you to watch the video

00:17 for which I have already provided you the link.

00:20 Okay, so in this lecture,

00:21 let's talk about the Kubernetes building blocks,

00:25 because if you talk about Amazon EK Service,

00:27 it is nothing but the wrapper over open source Kubernetes.

00:31 So it's important for us

00:32 to first understand the Kubernetes architecture.

00:35 Now, as I said earlier,

00:37 the purpose of this course is to focus only

00:43 on the networking part,

00:43 but I think it's essential to know all those core components

00:44 so that when we talk about the Kubernetes networking,

00:47 you understand what those components are.

00:49 Now, originally, Kubernetes was developed at Google.

00:52 But then Google made it open sourced,

00:54 and now Kubernetes as a project is maintained by CNCF,

00:58 which is Cloud Native Computing Foundation.

01:00 Now, CNCF was founded in 2015,

01:03 and the purpose was to really innovate

01:06 in the container space.

01:07 CNCF has a lot of projects,

01:09 but Kubernetes is one of the top project

01:12 which CNCF maintains as of today.

01:14 Okay, with that,

01:15 let's start with Kubernetes building blocks.

01:18 Now here we are talking about open source Kubernetes

01:21 to start with,

01:22 and then later we'll get into the EKS part of it.

01:24 Okay, if you look at Kubernetes from the top,

01:26 Kubernetes is deployed as a cluster,

01:29 and this cluster consists of control plane and a data plane.

01:32 As you might have guessed,

01:34 control plane is something which controls

01:36 what happens in the data plane,

01:38 and your actual applications runs in this data plane.

01:42 So control plane consists of master nodes,

01:45 and these nodes could be one or more,

01:47 but for high availability of those all control processes,

01:50 it is recommended that you always run multiple nodes

01:54 in the control plane.

01:55 Similarly, data plane consists of something called nodes.

01:59 You can treat them as like hosts,

02:01 so that when you deploy your application,

02:03 they are spread across multiple nodes.

02:06 So the nodes in this data planes are called worker nodes,

02:10 and the nodes in the control plane are called master nodes.

02:13 Now, when it comes to hosting the application,

02:16 these applications are hosted on the nodes,

02:19 but they're hosted as something called pods.

02:22 Now, pods are nothing but a smallest deployment unit

02:26 in Kubernetes.

02:27 Now, you always heard about the containers,

02:29 but then Kubernetes has the deployment unit as pod.

02:33 Now, one pod consists of one or more containers.

02:37 So basically you could have multiple containers

02:39 inside one pod.

02:41 But for Kubernetes, it always deploys pod,

02:44 not the container.

02:45 So it's very much possible

02:46 that you just have one container in the pod,

02:48 but more often or not,

02:50 you could have more than one container.

02:52 Maybe one application container and supporting databases

02:55 or cache.

02:56 So this kind of pods you can build,

02:59 so that application can work efficiently.

03:02 So pod ultimately represents

03:04 a group of one or more application containers.

03:07 So this is an high level architecture of the Kubernetes.

03:10 Now, let's see which components lies in the control plane

03:13 as well as in the data plane.

03:15 So this is a closer look at the cluster.

03:18 Now, on the left side, you have control plane,

03:20 and on the right side you have data plane.

03:22 And there are other components on the right.

03:24 You can see here this is a cloud control manager,

03:26 and we'll talk about that as well.

03:28 Now, important thing here to know that

03:31 when you are sitting outside of the cluster,

03:33 of course, as a person,

03:34 you would want to interact with the Kubernetes cluster.

03:37 Now, how does admin talk to the Kubernetes cluster?

03:41 So Kubernetes exposes the Kubernetes APIs

03:45 from the API server, which is hosted here,

03:47 and then admin will use either Kubernetes APIs

03:50 or there are some command line tools like kubectl,

03:53 which can be used to communicate with the Kubernetes.

03:56 And we'll see the entire deployment flow at high level

04:00 as we understand more about the control plane

04:02 and the data plane components.

04:03 So there are a lot of services or objects

04:06 in the Kubernetes term,

04:09 running in the control plane and the data plane,

04:11 and let's now understand those components.

04:15 So very first is kube-apiserver.

04:17 So as the name suggests,

04:18 kube-apiserver exposes the Kubernetes APIs.

04:21 That means if you want to communicate

04:24 with Kubernetes cluster from outside as an admin,

04:28 then you make an contact with API server,

04:31 and then API server will talk to the data plane

04:34 to make those adjustment to change the state

04:37 of Kubernetes cluster.

04:38 So it's a front-end for Kubernetes control plane.

04:42 Second is etcd, also called ETCD.

04:46 Now, this is a key value store as you know.

04:48 Right now,

04:49 this key value store maintains the state of your cluster.

04:51 For example, if you're deploying, say, different pods,

04:55 and what are the configuration of those pods,

04:57 you are exposing those pods as a service.

05:00 Now, what are the ports

05:01 on which these services will be accessible?

05:03 What are the port on which the pods will be accessible?

05:07 This is all the configuration information

05:09 that you provide in the form of manifest file

05:12 and all this configuration information,

05:14 and you can say the state of your entire cluster

05:17 is maintained in the key value store as in the etcd.

05:22 So it maintains all your cluster data.

05:24 So whenever some changes you have to make,

05:26 API call will make those changes persistent

05:29 into the etcd key value store.

05:32 And also if you want to get the state of your cluster,

05:35 API server will get that state from the cluster

05:37 and give it as an output on the command line or in the UI.

05:41 So etcd maintains the cluster information

05:45 into the persistent store.

05:48 Kube-scheduler, as the name suggests,

05:50 it actually keeps looking for the right place for your pod

05:55 on the nodes.

05:56 So maybe there are some nodes on which there is less load,

06:00 so kube-scheduler will decide how to launch

06:02 this particular pod on this particular node.

06:05 And there are a lot of parameters,

06:06 not just the compute hardware,

06:09 based on which it takes decision.

06:10 You can also change that behavior

06:14 based on node affinity and tented node.

06:18 There are many features in Kubernetes

06:20 with which you can decide this pod should go to this node

06:23 or that node.

06:24 Maybe some nodes have GPUs and your containers need GPU.

06:29 In that case, you can also change the behavior,

06:32 how scheduler will schedule that pod

06:34 to be running on the nodes.

06:35 So that's the job of a kube-scheduler.

06:38 Similarly, there is kube-controller-manager.

06:40 Now, kube-controller-manager consists

06:42 of multiple controller processes.

06:44 Now, as the name suggests, controller process does some job,

06:48 for example, if you want to schedule a job to be running

06:51 at certain time of the day.

06:54 So job controller will do that.

06:55 Similarly, if one of the node goes down,

06:58 then the node controller will identify

07:01 that the node has went down

07:03 and it'll make sure that another node is spun up.

07:05 Similarly, replication controller,

07:07 if there is one replica of the pod

07:09 and you want to make it clear replicas, for example,

07:12 then the replication controller will do that.

07:14 Endslice controller,

07:16 it basically enables the services to the pod communication.

07:21 So whenever you expose your pods as a service,

07:25 then there is a networking component called kube-proxy,

07:28 which does that.

07:28 And then EndpointSlice controller

07:30 will make sure that this communication or link

07:33 is established between the service and the pod.

07:36 Now, similarly, there is also cloud-controller-manager.

07:40 Now, Kubernetes can be done anywhere.

07:43 It can be done on premises,

07:44 and it can be run in the cloud as well.

07:47 And Kubernetes has extensible architecture,

07:51 which means you can integrate Kubernetes

07:53 with the cloud resources.

07:55 For example, Kubernetes has a load balancer as a service.

07:59 But then you can use instead,

08:01 cloud provider's load balancer.

08:02 For example, you can use application load balancer,

08:04 or network load balancer in Kubernetes.

08:07 Now, Kubernetes itself doesn't know

08:08 how to create application load balancer.

08:11 And for that you have the cloud-controller-manager,

08:14 through which you can extend the Kubernetes capabilities

08:17 to the cloud.

08:18 So AWS will provide AWS cloud-controller-manager.

08:21 Similarly, other cloud provider

08:22 will develop their own providers,

08:24 and you just plug it into the Kubernetes

08:26 and then it can provision those resources for you

08:30 when you make some deployments into the Kubernetes.

08:33 So likewise, these are the important processes

08:36 on the control plane side,

08:37 and this is very extensible, as I said.

08:39 You can put as many add-ons, which are available,

08:42 open source or third-party developed.

08:45 But these are the core Kubernetes control plane component.

08:49 Now, with that, let's move to the data plane.

08:52 As you know, data plane consists of nodes.

08:54 Nodes are nothing but the hosts.

08:56 And then nodes have essentially

08:57 three important components running.

09:01 As you can see there, nodes host the pods,

09:04 pods are nothing but one or more containers,

09:06 and which essentially means it runs your application.

09:09 Then every node has something called kubelet.

09:13 What is kubelet? It's an agent which runs on every node.

09:17 And kubelet is a agent which takes command

09:19 from the API server.

09:21 For example, API server says, "Run this pod."

09:25 Now how API server communicates with this node?

09:27 Because there is a kubelet running on that node.

09:30 So it's an agent that runs on each node in the cluster.

09:33 So it makes sure that the containers are running in a pod.

09:36 Similarly, kubelet also register the state of your pods

09:40 to the API server.

09:42 Suppose one of the pod goes down,

09:44 then kubelet will report it to the API server,

09:45 and API server will then add that to the ETCD, likewise.

09:52 Kube-proxy, now, this is very important.

09:53 Kube-proxy basically enables the network communication

09:56 to the pods from network station,

09:57 inside or outside of your cluster.

09:59 What it means that pods can communicate

10:01 with each other, right?

10:03 And when you want to expose pod as a service,

10:05 because maybe there are multiple pods for the same service,

10:08 of course, in order to scale that, right?

10:10 So you can expose your pod as a service.

10:13 So kube-proxy enables that creation

10:18 of the service basically.

10:19 And then you can also expose your services

10:22 to the external world, similar to the load balancer

10:25 and EC2 machine behind the load balancer.

10:27 You can also have your pods behind the load balancer.

10:30 So kube-proxy is the native Kubernetes networking component,

10:35 which enables all this communication.

10:39 Finally, container runtime.

10:41 Because you're running containers,

10:42 you need a container runtime engine inside this node,

10:45 for example, if you're using Docker,

10:48 then you would be having Docker engine.

10:50 Now, Docker underlying use Containerd

10:52 as a container runtime.

10:53 So in Kubernetes, on every node,

10:56 you need to have the similar container runtime.

10:59 Now, Kubernetes supports a lot of container runtimes,

11:01 not just Containerd,

11:03 but it also supports CRI based,

11:07 or CRI-based container runtime engine.

11:10 CRI is nothing but Container Runtime Interface.

11:12 And then there are many implementation of CRI.

11:17 So Kubernetes can very well use those as well.

11:20 But as of today, Containerd is the most popular one,

11:22 which is used by most of the leading container technologies.

11:27 So that's what the data plane looks like.

11:30 Now, let's look at the process

11:32 when you want to launch any pods, or say application,

11:36 inside the Kubernetes cluster,

11:38 then what that flow will look like.

11:40 So for example, there is a developer on the left side here.

11:43 You have your Kubernetes cluster on the right side,

11:45 and there are users of the application sitting here.

11:48 So developer, what it will do,

11:51 is write a code for your application, of course, right?

11:55 This code will then be unit tested, compile, build,

11:58 which ultimately produce some artifacts.

12:00 So maybe if it's a Java application,

12:03 it could be JAR or WAR file.

12:05 If it's a C or C-plus-plus code,

12:08 then it could be some binaries and libraries.

12:10 So that's an artifact which will ultimately be deployed.

12:14 Then you have DockerFile.

12:16 Now, DockerFile basically builds the Docker image.

12:19 Now, if you are aware of the Docker,

12:21 you must very well understand that, but ultimately,

12:24 from the instructions of the DockerFile,

12:26 where my code is or my deployables are,

12:30 and which port this container will be running,

12:33 or all this information is there in the DockerFile.

12:35 And basically DockerFile takes those instruction,

12:38 takes your code artifacts,

12:40 and build the Docker image out of it.

12:42 It will install required libraries, binary, everything,

12:45 and it will create a DockerFile out of it.

12:47 So you run the Docker build command,

12:49 and then it will create the image,

12:52 and then you push that image to the registry.

12:55 So Docker Hub is a public registry that you can use,

12:58 or if you're operating in AWS, then you can use Amazon ECR,

13:03 Elastic Container Registry.

13:05 There are many such registries available.

13:07 But ultimately you push your image

13:09 to the container registry.

13:12 So you build the image,

13:14 and now you want to deploy this image

13:16 into the Kubernetes cluster.

13:18 Now, for that developer or maybe the ops person

13:21 would write a deployment file,

13:24 also called as Kubernetes manifest file.

13:27 So this is a declarative file in the YAML format.

13:29 Basically tells Kubernetes how to deploy this application

13:33 to the Kubernetes cluster.

13:35 So somebody will write this deployment manifest file,

13:38 which will tell Kubernetes control plane

13:41 how to deploy this application.

13:43 So to tell Kubernetes API, you use some kind of tools.

13:49 Either you can use Kubernetes API,

13:51 which are available over HTTPS,

13:53 or Kubernetes has a command line tool call kubectl,

13:58 or kubectl, whatever you call it.

14:00 So kubectl will take your deployment file

14:03 and it will talk to your API server.

14:05 Of course, there will be authentication,

14:07 but we are not getting into that as of now.

14:09 So with kubectl and Deployment file,

14:12 it will reach to the API server as an instruction,

14:15 and API server will then communicate

14:17 with control manager ETCD scheduler,

14:20 and if required, to the cloud-controller-manager

14:23 to take a decision what to do about this deployment.

14:26 So it will make those calls,

14:28 and then finally it will talk to the kubelet

14:30 to deploy this to one of the node.

14:33 Now, kubelet receives those instruction.

14:36 What kubelet will do,

14:37 kubelet will communicate with the container runtime engine.

14:40 For example, Containerd in terms, in case of Docker,

14:43 container runtime engine will understand

14:45 that there is one Docker image,

14:47 which is available in Docker Hub,

14:48 which needs to be deployed as a container or as a pod.

14:51 So container runtime engine

14:52 will pull that image from the Docker Hub.

14:55 Now, for that container runtime engine

14:56 or a node would require permissions,

14:58 all that would be a part of authentication

15:00 and authorization.

15:02 But ultimately it will get that image

15:04 and then it will run it as a pod.

15:07 Now, once the pod is running,

15:09 of course it will be exposed to the external world

15:12 using the kube-proxy, or load balancer service,

15:15 but some kind of service will be created

15:18 and then the end users could access those over this service.

15:22 Now this is how you deploy the application,

15:24 and this application is available to the end user.

15:27 So this very high level flow,

15:29 and there are many steps in between which are skipped,

15:32 but hopefully you would understand

15:34 how typically things work in Kubernetes world.

15:37 So with that, we'll stop here.

15:39 For Kubernetes architecture,

15:41 I hope it is clear that Kubernetes has control plane

15:44 and data plane,

15:44 and what are the components

15:46 of those control plane and data plane.

15:49 With that, now, we'll move to the EKS architecture.

15:52 EKS is nothing but the Elastic Kubernetes Service in AWS.

15:56 And it is very much conformant

15:58 to the open source Kubernetes.

16:00 But we'll see how the architecture

16:02 of the Kubernetes cluster looks into the AWS world.

16:06 So thanks for watching and stay tuned. Thank you.