WEBVTT

0:00:02.820000 --> 0:00:09.440000
 Now I want to take a look at Kubernetes
 and what Kubernetes is and why

0:00:09.440000 --> 0:00:13.300000
 it matters. So we're going to go on
 a little Kubernetes crash course.

0:00:13.300000 --> 0:00:18.440000
 In this video, what we're going to
 cover are the following topics.

0:00:18.440000 --> 0:00:23.440000
 We're going to start out talking about
 what Kubernetes is and why it matters.

0:00:23.440000 --> 0:00:29.060000
 We'll talk about deploying or what
 the Azure Kubernetes services, how

0:00:29.060000 --> 0:00:32.360000
 that implements Kubernetes
 in the Azure environment.

0:00:32.360000 --> 0:00:37.520000
 And then we'll talk about the components
 of the Azure Kubernetes service.

0:00:37.520000 --> 0:00:41.380000
 And what I want to do is I want to
 dive right into what Kubernetes is

0:00:41.380000 --> 0:00:43.200000
 and why it matters.

0:00:43.200000 --> 0:00:46.860000
 So let's take a look at
 a bit of a whiteboard.

0:00:46.860000 --> 0:00:54.540000
 I've got a containerized solution and with
 what I call standalone containerized

0:00:54.540000 --> 0:00:59.080000
 solution, I've got a host and
 we will name this host.

0:00:59.080000 --> 0:01:06.100000
 And then that host is running a in
 addition to its OS and everything.

0:01:06.100000 --> 0:01:10.800000
 It's running a container management solution
 and we'll say Docker because

0:01:10.800000 --> 0:01:14.960000
 that's a pretty common container management
 solution, although not the

0:01:14.960000 --> 0:01:20.880000
 only one. And then that host is running
 a bunch of containers, right?

0:01:20.880000 --> 0:01:23.420000
 But eventually those containers, even
 though they're lighter weight than

0:01:23.420000 --> 0:01:28.720000
 a virtual machine, they are going to
 use up the resources of that host,

0:01:28.720000 --> 0:01:31.020000
 right? So what I need to think about
 then is saying, okay, it would be

0:01:31.020000 --> 0:01:33.480000
 really cool, as I can say, all right,
 let's go ahead and add another host

0:01:33.480000 --> 0:01:38.280000
 here. And we can set it up
 basically the same way.

0:01:38.280000 --> 0:01:49.800000
 All right, and then awesome, we can
 run a bunch of containers on that.

0:01:49.800000 --> 0:01:53.560000
 But what if these containers
 are related?

0:01:53.560000 --> 0:01:57.360000
 Let's say for example,
 I've got a web app.

0:01:57.360000 --> 0:02:02.440000
 And that web app, I need four instances
 of that container, cuz I'm scaling

0:02:02.440000 --> 0:02:11.760000
 this, right? And I want to, let's go
 over here, I should have only said

0:02:11.760000 --> 0:02:16.000000
 two, that's more typing than you need
 to watch, but we'll get there.

0:02:16.000000 --> 0:02:19.400000
 All right, so I've got these four
 instances of the web app, right?

0:02:19.400000 --> 0:02:23.880000
 But I have to think about this
 kind of as a holistic solution.

0:02:23.880000 --> 0:02:28.720000
 I don't want a user having to think
 about those four web apps, right?

0:02:28.720000 --> 0:02:30.820000
 I've got a user over here.

0:02:30.820000 --> 0:02:36.040000
 The user's going in, they just, as far
 as they know, they're just going

0:02:36.040000 --> 0:02:37.660000
 to my web app, right?

0:02:37.660000 --> 0:02:39.440000
 So they're going to web app.

0:02:39.440000 --> 0:02:44.280000
 And then I need to think about all sorts
 of things like load balancing.

0:02:44.280000 --> 0:02:47.320000
 Is that going, is that request going
 to go to this one or is it going

0:02:47.320000 --> 0:02:51.100000
 to go over here to this other web app,
 etc, that other instances of the

0:02:51.100000 --> 0:02:54.800000
 container? And, and you know,
 what if I'm scaling out?

0:02:54.800000 --> 0:02:56.420000
 Where do these web apps go?

0:02:56.420000 --> 0:02:58.720000
 Where do these instances
 of the container go?

0:02:58.720000 --> 0:03:02.740000
 And so what I really need is I need
 some kind of solution that's going

0:03:02.740000 --> 0:03:04.180000
 to handle this for me.

0:03:04.180000 --> 0:03:09.980000
 And that's where clustering solutions
 for containerized environments come

0:03:09.980000 --> 0:03:16.920000
 into play. And Kubernetes has become
 the de facto standard for container

0:03:16.920000 --> 0:03:20.520000
 clusterization. It was originally
 developed by Google internally.

0:03:20.520000 --> 0:03:22.780000
 They have made it open source.

0:03:22.780000 --> 0:03:24.980000
 They're still highly
 involved in this.

0:03:24.980000 --> 0:03:27.880000
 Microsoft is involved with it as well
 as are of course many others in

0:03:27.880000 --> 0:03:30.000000
 the open source community, right?

0:03:30.000000 --> 0:03:32.360000
 And it really has just
 become the standard.

0:03:32.360000 --> 0:03:36.120000
 And it's going to give us certain
 capabilities, right?

0:03:36.120000 --> 0:03:39.820000
 When I set up a Kubernetes
 environment, okay?

0:03:39.820000 --> 0:03:45.360000
 That's going to give me things
 like cluster management.

0:03:45.360000 --> 0:03:49.580000
 Okay, it's going to give me
 things like scalability.

0:03:49.580000 --> 0:03:54.640000
 Scalability, there
 we go, I can spell.

0:03:54.640000 --> 0:04:01.860000
 It's going to give me potentially
 load balancing capabilities.

0:04:01.860000 --> 0:04:07.080000
 Okay, and it's going to give me things
 like monitoring capabilities.

0:04:07.080000 --> 0:04:11.220000
 Okay, now these are all things that
 you could do, that you could set up,

0:04:11.220000 --> 0:04:17.080000
 and you could go with what I would consider
 the most basic type of clustering,

0:04:17.080000 --> 0:04:19.000000
 which is a Docker swarm.

0:04:19.000000 --> 0:04:21.720000
 And you could add your own functionality
 to do all this.

0:04:21.720000 --> 0:04:26.200000
 But the thing with Kubernetes is that
 it's going to package that for you.

0:04:26.200000 --> 0:04:27.680000
 Okay, now Kubernetes
 is open source.

0:04:27.680000 --> 0:04:29.080000
 It's cross platform.

0:04:29.080000 --> 0:04:31.000000
 You can run this pretty
 much anywhere.

0:04:31.000000 --> 0:04:38.220000
 And if you're going to run an enterprise
 level implementation of a containerized

0:04:38.220000 --> 0:04:42.400000
 solution, it is highly likely that you're
 going to want to run it in Kubernetes.

0:04:42.400000 --> 0:04:47.080000
 Or at the minimum, you want to look
 at Kubernetes as a hosting solution.

0:04:47.080000 --> 0:04:50.800000
 Again, there are others out there, but
 this really has become the standard.

0:04:50.800000 --> 0:04:58.580000
 Now, let's talk about how Kubernetes
 works in the Azure environment.

0:04:58.580000 --> 0:05:02.160000
 So we're going to take a look at
 the Azure Kubernetes service.

0:05:02.160000 --> 0:05:06.900000
 First of all, the Azure Kubernetes service
 is a managed Kubernetes cluster,

0:05:06.900000 --> 0:05:11.960000
 right? And that means that it's being presented
 to you as a platform service,

0:05:11.960000 --> 0:05:13.400000
 right? So you're not going
 to spin up the hosts.

0:05:13.400000 --> 0:05:15.460000
 You're not going to
 install Kubernetes.

0:05:15.460000 --> 0:05:16.880000
 You're not going to
 update Kubernetes.

0:05:16.880000 --> 0:05:20.100000
 All of that is being
 done by Azure.

0:05:20.100000 --> 0:05:25.380000
 So if you think about Kubernetes really
 just about any clustering solution,

0:05:25.380000 --> 0:05:29.180000
 you're going to have master nodes and
 you're going to have worker nodes

0:05:29.180000 --> 0:05:33.940000
 or agent nodes. Okay, the master
 node is managed by Azure.

0:05:33.940000 --> 0:05:35.760000
 Right? That means you're
 not setting it up.

0:05:35.760000 --> 0:05:38.120000
 It means you're not paying
 for the master node.

0:05:38.120000 --> 0:05:40.460000
 All you're paying for is
 the actual execution.

0:05:40.460000 --> 0:05:43.760000
 You're paying for what we
 will call the agent nodes.

0:05:43.760000 --> 0:05:50.000000
 Okay? All of the infrastructure is
 provisioned and managed by Azure.

0:05:50.000000 --> 0:05:53.120000
 So you say, okay, I need to
 have three nodes with this.

0:05:53.120000 --> 0:05:56.420000
 It's going to provision three virtual
 machines as agent nodes.

0:05:56.420000 --> 0:05:58.220000
 Right? It's going to provision
 the virtual network.

0:05:58.220000 --> 0:05:59.720000
 It's going to configure
 all of that.

0:05:59.720000 --> 0:06:01.200000
 It's going to give you
 a load balancer.

0:06:01.200000 --> 0:06:08.560000
 It makes it very easy for you to deploy
 enterprise class solutions.

0:06:08.560000 --> 0:06:11.900000
 I mean, look, it's never snap your fingers
 easy to deploy an enterprise

0:06:11.900000 --> 0:06:17.180000
 class solution, but this takes a lot of
 the frictional way from that process.

0:06:17.180000 --> 0:06:21.620000
 And again, you are not paying
 for the management of this.

0:06:21.620000 --> 0:06:24.780000
 You're just paying for the active nodes
 or the agent nodes that are running

0:06:24.780000 --> 0:06:27.140000
 your workloads. Okay?

0:06:27.140000 --> 0:06:27.940000
 So that's kind of nice.

0:06:27.940000 --> 0:06:32.280000
 Now, you also have auto
 scale capabilities.

0:06:32.280000 --> 0:06:34.460000
 And there's an asterisk by that.

0:06:34.460000 --> 0:06:39.400000
 There's node level auto scaling and
 there is pod level auto scaling.

0:06:39.400000 --> 0:06:43.820000
 What is a pod? A pod is
 a unit of deployment.

0:06:43.820000 --> 0:06:48.080000
 Right? And a pod is typically a container,
 but it can be more than that.

0:06:48.080000 --> 0:06:51.480000
 It can be a container and resources
 that it requires.

0:06:51.480000 --> 0:06:54.560000
 I will typically just to kind of
 keep things straight in my mind.

0:06:54.560000 --> 0:06:57.060000
 And this is not an
 exact definition.

0:06:57.060000 --> 0:07:00.240000
 I kind of equate pod
 and container.

0:07:00.240000 --> 0:07:02.720000
 Again, even though a pod can
 be a bit more than that.

0:07:02.720000 --> 0:07:06.000000
 But just to keep it easy, if you've
 never seen Kubernetes before.

0:07:06.000000 --> 0:07:09.120000
 All right. And so you can actually
 set up auto scaling for your pods.

0:07:09.120000 --> 0:07:12.840000
 So that if I've got a particular pod,
 let's say my web app and the load

0:07:12.840000 --> 0:07:16.560000
 on that is exceeding some threshold,
 then I can spawn additional instances

0:07:16.560000 --> 0:07:23.300000
 of that pod. You can also auto
 scale your agent nodes.

0:07:23.300000 --> 0:07:25.620000
 Okay. So in other words, an agent
 node is really just a VM.

0:07:25.620000 --> 0:07:30.360000
 Okay. And then if the load on that
 VM or those VMs gets too high, you

0:07:30.360000 --> 0:07:32.220000
 can auto scale additional nodes.

0:07:32.220000 --> 0:07:36.380000
 However, that feature, the auto scale
 for the nodes at the time of this

0:07:36.380000 --> 0:07:39.600000
 recording is in preview.

0:07:39.600000 --> 0:07:44.740000
 And it also requires that you specify
 that you use a virtual machine scale

0:07:44.740000 --> 0:07:50.940000
 set as your agent infrastructure, which
 is also in preview, which probably

0:07:50.940000 --> 0:07:52.180000
 why the whole thing is in preview.


0:07:52.180000 --> 0:07:53.500000
 But be aware of that.

0:07:53.500000 --> 0:07:55.380000
 That's something to look at by
 the time you watch this video.

0:07:55.380000 --> 0:07:58.800000
 It may actually be in general availability,
 but again, definitely something

0:07:58.800000 --> 0:08:00.120000
 to keep your eye on.

0:08:00.120000 --> 0:08:04.700000
 Okay. So you could potentially set up
 so that you've got a fully automated

0:08:04.700000 --> 0:08:09.740000
 enterprise scale solution, which is
 pretty cool, all containerized.

0:08:09.740000 --> 0:08:14.440000
 Okay. You also with Kubernetes
 have role based access control.

0:08:14.440000 --> 0:08:19.060000
 So Kubernetes, you think about the workload
 and the requirements of getting

0:08:19.060000 --> 0:08:22.920000
 in there and using the workload, but
 then you also have the management

0:08:22.920000 --> 0:08:24.220000
 of Kubernetes itself.

0:08:24.220000 --> 0:08:27.480000
 And when I talk about role based access
 control for Kubernetes, I'm really

0:08:27.480000 --> 0:08:29.380000
 talking about the management
 of the service.

0:08:29.380000 --> 0:08:34.520000
 So, you know, things like deployments,
 things like node management, things

0:08:34.520000 --> 0:08:36.660000
 like monitoring, right?

0:08:36.660000 --> 0:08:38.260000
 All of these can be controlled.

0:08:38.260000 --> 0:08:42.760000
 Access to these features can be controlled
 through role based access control,

0:08:42.760000 --> 0:08:44.900000
 which is tied to Azure AD.

0:08:44.900000 --> 0:08:47.600000
 There's also integrated logging.

0:08:47.600000 --> 0:08:51.740000
 When you provision Kubernetes, you're
 going to set Kubernetes up typically

0:08:51.740000 --> 0:08:57.360000
 to log directly to an instance
 of what was log analytics.

0:08:57.360000 --> 0:08:58.820000
 I'm trying to use the
 right term now.

0:08:58.820000 --> 0:09:00.800000
 It's a Azure monitor.

0:09:00.800000 --> 0:09:02.400000
 They're kind of blending
 two things.

0:09:02.400000 --> 0:09:05.620000
 By the time you watch this again, probably
 it'll all just be called Azure

0:09:05.620000 --> 0:09:07.560000
 monitor. You'll hear
 me say log analytics.

0:09:07.560000 --> 0:09:10.260000
 That's moving to one
 integrated solution.

0:09:10.260000 --> 0:09:13.140000
 Anyways, that's what you're
 going to use for logging.

0:09:13.140000 --> 0:09:17.540000
 So, that's already built in, which
 is pretty cool capability.

0:09:17.540000 --> 0:09:21.740000
 And you also have a number
 of ingress options.

0:09:21.740000 --> 0:09:25.220000
 Are you going to come in
 through a load balancer?

0:09:25.220000 --> 0:09:29.240000
 You can also actually set up auto load
 balancing, which in addition to

0:09:29.240000 --> 0:09:34.780000
 load balance, it will also automatically
 generate unique DNS names, fully

0:09:34.780000 --> 0:09:39.020000
 qualified domain names, for any service
 that needs a public endpoint that's

0:09:39.020000 --> 0:09:40.880000
 being hosted within Kubernetes.

0:09:40.880000 --> 0:09:46.760000
 And you can also do things like use
 a application gateway as your front

0:09:46.760000 --> 0:09:52.480000
 end and configure that to provide access
 to workloads running within the

0:09:52.480000 --> 0:09:55.680000
 Azure Kubernetes service.

0:09:55.680000 --> 0:09:57.660000
 All right, so that's the
 Kubernetes service.

0:09:57.660000 --> 0:10:01.680000
 Long story short, you're using Kubernetes,
 which is this, again, pretty

0:10:01.680000 --> 0:10:05.800000
 much the de facto standard for
 container cluster solutions.

0:10:05.800000 --> 0:10:08.920000
 And you're using it as
 a platform service.

0:10:08.920000 --> 0:10:14.700000
 So, Azure is managing really those components
 that are not directly related

0:10:14.700000 --> 0:10:18.400000
 to the workload that you're hosting,
 or workloads ideally that you're

0:10:18.400000 --> 0:10:23.860000
 hosting. Now, let's take a look at the
 components that make up the Azure

0:10:23.860000 --> 0:10:25.060000
 Kubernetes service.

0:10:25.060000 --> 0:10:27.940000
 Now, the reality is you're probably
 not going to have to deal with these

0:10:27.940000 --> 0:10:30.700000
 directly too often, but
 this is what we have.

0:10:30.700000 --> 0:10:35.240000
 First of all, within Azure, managed by
 Azure, you have the cluster master.

0:10:35.240000 --> 0:10:39.000000
 The cluster master is going to be,
 it's a node, you just don't see it.

0:10:39.000000 --> 0:10:43.020000
 You literally have no direct access
 to the cluster manager that's fully

0:10:43.020000 --> 0:10:46.380000
 managed by Azure.

0:10:46.380000 --> 0:10:52.720000
 However, there are multiple components
 on the cluster manager that you

0:10:52.720000 --> 0:10:54.400000
 do want to know about.

0:10:54.400000 --> 0:10:58.400000
 First of all, and I think probably from
 anyone who's managing its perspective,

0:10:58.400000 --> 0:11:01.640000
 most importantly, it
 has an API server.

0:11:01.640000 --> 0:11:09.700000
 That API server is how you are going to
 manage your Kubernetes implementation.

0:11:09.700000 --> 0:11:12.820000
 Simple as that. That's giving you the
 API that's going to work with the

0:11:12.820000 --> 0:11:16.160000
 CLI tools that are built in that
 are available for Kubernetes.

0:11:16.160000 --> 0:11:21.360000
 You have the ETCD, which is giving
 you durable configuration storage.

0:11:21.360000 --> 0:11:25.320000
 So, as you configure your containers
 and runtime conditions, those are

0:11:25.320000 --> 0:11:27.320000
 being stored in durable storage.

0:11:27.320000 --> 0:11:29.980000
 That's really just a key
 value pair system.

0:11:29.980000 --> 0:11:36.280000
 You've got a scheduler and the scheduler
 does things like keeping track

0:11:36.280000 --> 0:11:40.920000
 of deployments, scaling deployments within
 the overall Kubernetes environment.

0:11:40.920000 --> 0:11:44.360000
 Then, on the cluster manager, you
 have the controller manager.

0:11:44.360000 --> 0:11:49.500000
 The controller manager manages to use
 a technical term, a bunch of little

0:11:49.500000 --> 0:11:58.040000
 minor or smaller controllers that do
 specific things such as managing

0:11:58.040000 --> 0:12:02.280000
 application, pod replication,
 interaction with storage, etc.

0:12:02.280000 --> 0:12:08.240000
 That's all on the cluster master, which
 again is fully managed by Azure.

0:12:08.240000 --> 0:12:13.000000
 Then, in addition to the cluster
 master, you have agent nodes.

0:12:13.000000 --> 0:12:19.780000
 The agent nodes are technically managed
 by you, although there's really

0:12:19.780000 --> 0:12:22.240000
 not much you're going to have to do,
 for example, at the virtual machine

0:12:22.240000 --> 0:12:24.220000
 level, because that should
 all be set up for you.

0:12:24.220000 --> 0:12:26.380000
 They're going to have all the
 software installed on them.

0:12:26.380000 --> 0:12:29.240000
 You are paying for them, so
 that's kind of important.

0:12:29.240000 --> 0:12:33.260000
 Now, what gets installed
 on the actual nodes?

0:12:33.260000 --> 0:12:36.680000
 First of all, you've got the
 what's called Kubilett.

0:12:36.680000 --> 0:12:39.780000
 You'll see Kubilett often
 with Kubernetes.

0:12:39.780000 --> 0:12:43.320000
 This is really the
 glue, if you will.

0:12:43.320000 --> 0:12:45.800000
 This is the component that makes
 this work as a cluster.

0:12:45.800000 --> 0:12:51.380000
 Doing all the cluster communications
 when a container gets scheduled for

0:12:51.380000 --> 0:12:54.580000
 a node, that schedule is going
 to come through the Kubilett.

0:12:54.580000 --> 0:12:58.580000
 That's really just your infrastructure
 processing.

0:12:58.580000 --> 0:13:03.340000
 Now, in addition to that, we have
 a runtime, a container runtime.

0:13:03.340000 --> 0:13:07.000000
 Now, I keep talking about Docker, because
 it's going to be a very common

0:13:07.000000 --> 0:13:10.440000
 container runtime, but I've mentioned
 there are other container runtimes.

0:13:10.440000 --> 0:13:14.280000
 In the case of the Azure Kubernetes
 service, that runtime is actually

0:13:14.280000 --> 0:13:16.340000
 something called Moby.

0:13:16.340000 --> 0:13:18.940000
 It's just a different runtime.

0:13:18.940000 --> 0:13:21.720000
 That runtime is going
 to run your container.

0:13:21.720000 --> 0:13:24.140000
 Of course, it's not necessarily
 just one container.

0:13:24.140000 --> 0:13:28.300000
 You're going to run multiple
 containers within your node.

0:13:28.300000 --> 0:13:33.700000
 Those can be scaled, and they can
 be potentially auto-scaled.

0:13:33.700000 --> 0:13:38.360000
 You can move from, or the system can
 move them from one node to another,

0:13:38.360000 --> 0:13:44.760000
 etc. You have self-healing container,
 lots of capabilities within the

0:13:44.760000 --> 0:13:46.100000
 Kubernetes environment.

0:13:46.100000 --> 0:13:52.340000
 There's one other component that's going
 to be on the node, on the agent

0:13:52.340000 --> 0:13:53.480000
 node, that's managed by you.

0:13:53.480000 --> 0:13:55.040000
 That's going to be the proxy.

0:13:55.040000 --> 0:13:58.900000
 Really, what that's doing is that's
 serving as a link between any kind

0:13:58.900000 --> 0:14:01.780000
 of outside access.

0:14:01.780000 --> 0:14:07.120000
 If I've got a user, and that user needs
 to get to a web app that's running

0:14:07.120000 --> 0:14:11.440000
 on the container, they're not going
 to go directly to the container.

0:14:11.440000 --> 0:14:13.960000
 What they're going to do is they're
 going to go through the proxy, which

0:14:13.960000 --> 0:14:18.620000
 is going to do exactly what it sounds
 like, and proxy, your communications,

0:14:18.620000 --> 0:14:22.980000
 drew that the wrong way,
 with the container.

0:14:22.980000 --> 0:14:29.240000
 Those are the components that are used
 in the Azure Kubernetes service.

0:14:29.240000 --> 0:14:30.540000
 Very quick recap.

0:14:30.540000 --> 0:14:31.460000
 What is Kubernetes?

0:14:31.460000 --> 0:14:36.480000
 It's at the heart of it, a clustering solution
 for containerized environment.

0:14:36.480000 --> 0:14:38.300000
 What is Azure Kubernetes service?

0:14:38.300000 --> 0:14:43.180000
 It is a platform implementation platform
 as a service implementation of

0:14:43.180000 --> 0:14:47.560000
 Kubernetes, where many of the components
 and complexities are managed

0:14:47.560000 --> 0:14:52.280000
 within Azure. And then we've covered
 the various components that go into

0:14:52.280000 --> 0:14:56.480000
 that are used that are under the hood
 within Azure Kubernetes service.