Fleetman Microservices in Kubernetes

A free video tutorial from Richard Chesterwood
Software developer at VirtualPairProgrammers
Rating: 4.6 out of 5Instructor rating
7 courses
130,452 students
Fleetman Microservices - setting the scene

Learn more from the full course

Kubernetes Hands-On - Deploy Microservices to the AWS Cloud

Use Kubernetes to deploy a Microservice architecture. You'll deploy, manage and monitor a live Kubernetes cluster.

28:31:23 of on-demand video • Updated May 2024

Deploy containers to a Kubernetes Cluster
Run Kubernetes in AWS using either EKS or Kops
Monitor a live Kubernetes cluster using Prometheus and Grafana
Analyse system-wide logs using the ELK Stack (ElasticStack); Kibana and ElasticSearch
Handle Alerts in a Kubernetes cluster by notifying Slack Channels
Understand how Requests and Limits work in Kubernetes
Use Kubernetes Horizontal Pod Autoscaling
Configure Ingress Control on a live Kubernetes deployment
Understand Kubernetes StatefulSets
Integrate Kubernetes with a Continuous Deployment System (CD)
Use Helm to Manage Charts and to Dynamically Update your Kubernetes YAML
Richard: So for this course, I'm giving you the scenario where you've been given a system by a development team and they've already built a series of Docker images. And your job as the operations engineer is to get it deployed to the cloud. Now I know that in real life many of you watching this will be working as a dev ops engineer or maybe you're aiming to become a dev ops engineer. So that's when you're working on both the development and the deployment of the system. So I've laid on for you a series of pre-built images, DockerHub.com under the Richard Chesterwood repository and your job in this section of the course is to assemble these together and we'll need to decide whether these are pods, replica sets, or deployments. And you've got to piece them together a bit like a jigsaw puzzle. Now there's only five images on this system because I've created what is really the most basic microservice system possible. But it's still a system with a reasonable amount of complexity, it's certainly not a hello world application. But of course we can't just start deploying these images without you having some understanding of the architecture of the system and how it was deployed. So on this video I'm going to give you a full overview of this microservice system. This is a high level diagram of how all of the Docker images in the system hang together. Each of these boxes here, one, two, three, four, five, relates to the Docker images that you've just seen on DockerHub. This is a system that I've been using for a few years now whenever I do any training courses based around microservices or similar technologies. The aim is that it's complicated enough to illustrate all of the concepts without it being so complicated that it's overwhelming. It makes a really good case study. Although this is designed to be a simple cut down system, there's still a reasonable amount of complexity in this system. I don't want you to feel overwhelmed by that even if you don't understand the inner workings of the system, you're still going to be able to deploy. However, for this video I'm going to take you through the architecture of the system and explain what each of these pieces are and how it all fits together. The system that we're deploying on this course is a system for some kind of transport company that needs to track its vehicles as they move around the country. So it's something like delivery trucks moving around the country. Each of the vehicles is equipped with a Global Positioning System and periodically, maybe every 10 seconds or so, a vehicle will report its current position back to our central server. And we're going to have many of these vehicles out in the field constantly reporting their positions. Now of course the difficulty is we don't have any real vehicles. And that allows me to introduce you to the first of the microservices. This one here is the microservice called the position simulator. And as the name suggests, this microservice is going to simulate those vehicles moving around the country. It's a very simply microservice. You really don't need to understand any of the code in this system. Remember, our job is just to deploy the system to the cloud, but I know that many of you will be interested in looking at the deep internals of this system, and you can find all of the code for this system on my GitHub repository called K8s-fleetman. And my user name on GitHub is DickChesterwood. Now on real development projects, I tend to keep each microservice as a repository in its own right, but to keep things simple and because GitHub at the time of recording doesn't have a good way of grouping together related repositories, I've decided just to make this one single repository with a folder for each microservice. Every one of the services starts with the phrase K8s for Kubernetes of course dash fleetman dash followed by whatever the name of the service, microservice, or subsystem is called. So here is the position simulator. It happens to be implemented in Java and I'm using Spring Boot. As I say, it really doesn't matter if you're familiar with those technologies. I just want to show you really where the data is coming from. So on this particular microservice, when it starts up it reads in a series of files. And inside those files are some test data to simulate vehicles. And it just runs as an infinite loop really, and randomly every few seconds it reads from the file. Let me show you what these files look like under the SRC folder and then under main. And then under resources, and then under tracks, here's a series of test files that I've generated. Each file represents a single vehicle. The name of the vehicle is just the name of the file and we're going to be seeing these names appearing in the front end. If you wanted to add more vehicles to this you would just create a new file, you would just create a new file in this directory. If you want to have a look inside any of them, you'll see there isn't really much of a structure in here, it's just a long series of latitude and longitudes, in other words positions on planet Earth. And I've generated these files just by taking some GPS tracks that you can find from various sources online. Every time that position simulator reads in one of these latitude and longitudes, of course it needs to do something with it. One of the goals of microservices is that a single microservice should only do one thing. Now in the case of the position simulator, then that one thing of course is going to be simulating positions. Once it's read in one of these positions from a file, really the job of this microservice is over. So it needs to hand that data somewhere else. So as that microservice generates simulated positions, it sends those positions off to a queue. And a queue is a very common aspect of a microservice architecture. It allows us to send data across the system without coupling the microservice together. For this system, I'm using a queue called ActiveMq. I don't know if you've come across that queue before, there's a lot of different choices that we could make here, I just happen to be quite familiar with ActiveMq, it's quite a simple queue to work with. The queue, just like all of the rest of the system is implemented as a Docker container. It's this one called K8s-fleetman-queue. Over to GitHub, you will find there is a folder for the queue as well. This is by far the simplest of the components in this system because it's just a single Docker file. If you look in the Docker file, this container is built from a standard download from Apache.org. The next microservice in the system is the one called position tracker, and certainly for this system this is the most important of the microservices. The job of this microservice is to read the positions from the queue and to do various calculations on those positions. It's going to be, for example, calculating the speed of the vehicles. This microservice is also going to form a repository for the vehicles as well so that we can do things such as store the history of where the vehicles have been. And we'll be talking more about that bit later on in the course when we start to work with databases. Just a quick word on my notation here, you'll notice that I've got the arrow pointing towards the queue even though, as you just saw from the animation there, the data, the vehicle positions are going in this direction. Now when I've used this diagram on previous courses I've had a lot of questions about that. I've never been entirely sure which way around this arrow should go really, but technically in UML, which is the notation I'm using here, the arrow indicates a dependency. And this microservice is dependent on the queue, so that's what I'm representing with the arrow here. I'm not actually representing the direction of the data flow, I hope that makes sense. So those three components represents really the entire back end of this system, it is a simple system. Of course in real life we would have many many more microservices, but that's enough for this system. So of course we're going to have a front end to all of this and for this particular system this is going to be a JavaScript application. It happens to be implemented using Angular. Now the last major component that we need is a so called API gateway. The reason that this is necessary is of course somehow the JavaScript application here on the left is going to need to communicate with the backend system, it's going to need to somehow communicate with these microservices. And that would definitely be a bad thing if we allowed the JavaScript code here to directly call any of the microservices. The reason is the backend system is going to constantly change as the system is being upgraded and modified and generally engineered, the microservices are going to change. Remember, the microservices are very small, so it's inevitable that there's going to be changes. Very quickly I can imagine that this position tracker is going to get more and more complicated, and very soon we're going to want to split that microservice into separate microservices. And sometimes the opposite happens, sometimes you realise that two microservices are too small and need to be merged together. So the back end is going to be in a constant state of flux. Now, if we allowed the front end JavaScript to directly reference any of these microservices, then of course every time we made a change to any of these microservices, we'd also have to go through all of the JavaScript code and we'd have to make all of the relevant changes. So that would definitely be what's considered an anti-pattern, and we never allow the front end code to directly reference the microservices. For that reason, we introduce one final component called the API gateway. The idea of the API gateway is very simple. This becomes the single point of entry to the entire application. From now on the JavaScript code is only going to be allowed to reference this API gateway. The API gateway is quite a simple component. Its job is to delegate any calls to the appropriate microservices. And typically the API gateway contains some sort of logic that maps the incoming requests to the underlying microservices. So the JavaScript here might make a rest call, it doesn't have to be a rest call, but it could be, to some URL, which is intercepted by the API gateway and then it will use some logic to determine how that call should be handled. The logic in the API gateway is typically some kind of a mapping. So it would be something like if the incoming request ends with /vehicles, then delegate the call to, in this case, the position tracker. So this means that as we engineer the microservices, we add new microservices, we split up microservices and so on, the engineers just have to make the corresponding changes here in the very simple API gateway. The front end is then isolated from any changes. Now I'm struggling here because I know that many of you will have already been familiar with API gateways, and that many of you will be new to it, so it's hard to get the level right here, but if you want further information on this, then check out the URL that I'm showing here, which is a great introduction to the API gateway pattern. So remember, you don't need to know the deep implementation details of any of the system, it's just out job to deploy the system. So you know now the purpose for each of these five Docker images, let's get this turned into a Kubernetes deployment.