Setting Up A Kubernetes Cluster For Udemy Microservices

by Henrik Larsen 56 views

Hey guys! Today, we're diving into the exciting world of Kubernetes and how to set up a cluster specifically tailored for our microservices. If you've been following along with the Udemy microservices course (udemy-microsrv), you know we've got a bunch of cool services to deploy. We're going to walk through the entire process, step by step, to ensure you have a robust and scalable environment for your applications. Get ready to roll up your sleeves and get your hands dirty with some real-world DevOps magic!

Creating the Helm Project: udemy-microsrv-cluster

First things first, let's talk about Helm. If you're not familiar, Helm is basically the package manager for Kubernetes. Think of it like apt or yum for your operating system, but for Kubernetes applications. Helm allows us to define, install, and upgrade even the most complex Kubernetes applications. We're going to use it to manage our microservices deployments, making our lives much easier. To kick things off, we need to create a Helm project named udemy-microsrv-cluster. This will be the home for all our Kubernetes configurations.

To create a Helm project, you'll need to have Helm installed on your machine. If you don't have it yet, head over to the official Helm website and follow the installation instructions. Once you have Helm installed, creating a new project is super simple. Just open your terminal and run the following command:

helm create udemy-microsrv-cluster

This command will scaffold a new directory named udemy-microsrv-cluster with a basic Helm chart structure. Inside this directory, you'll find a few important files and folders:

  • Chart.yaml: This file contains metadata about your Helm chart, such as the name, version, and description.
  • values.yaml: This file is where you define the default values for your chart's configurable parameters. We'll be tweaking this file quite a bit as we add our microservices.
  • charts/: This directory is for any dependent charts that your chart relies on. We won't need this for our basic setup, but it's good to know it's there.
  • templates/: This is the heart of our Helm chart. This directory contains the Kubernetes manifest files (like Deployments and Services) that Helm will use to deploy our applications. We'll be spending most of our time in this directory.

Now that we have our Helm project set up, let's dive into adding our first microservice: NATS.

Adding Deployment and Service for NATS

NATS is a lightweight, high-performance messaging system that we'll use for communication between our microservices. It's a crucial component of our architecture, so let's get it up and running in our Kubernetes cluster. We need to create both a Deployment and a Service for NATS. The Deployment will ensure that we have a certain number of NATS pods running, and the Service will provide a stable endpoint for other services to connect to NATS.

First, let's create the Deployment. Inside the templates/ directory of our Helm chart, create a new file named nats-deployment.yaml. Open this file in your favorite text editor and paste the following YAML configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nats
  labels:
    app: nats
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nats
  template:
    metadata:
      labels:
        app: nats
    spec:
      containers:
      - name: nats
        image: nats:latest
        ports:
        - containerPort: 4222
          name: client
        - containerPort: 8222
          name: monitoring

Let's break down this configuration. We're creating a Deployment named nats with one replica. This means Kubernetes will ensure that there's always one NATS pod running. The template section defines the pod specification, which includes the container image (nats:latest) and the ports that NATS will listen on (4222 for client connections and 8222 for monitoring). It's important to label the deployment correctly so that our Service can discover and route traffic to our NATS pods.

Next, we need to create the Service. In the same templates/ directory, create a new file named nats-service.yaml and add the following YAML:

apiVersion: v1
kind: Service
metadata:
  name: nats
  labels:
    app: nats
spec:
  selector:
    app: nats
  ports:
  - port: 4222
    targetPort: 4222
    name: client
  - port: 8222
    targetPort: 8222
    name: monitoring
  type: ClusterIP

This Service is named nats and selects pods with the label app: nats, which matches the labels we defined in our Deployment. It exposes ports 4222 and 8222, mapping them to the corresponding ports on the NATS pods. The type: ClusterIP means that this Service will only be accessible within the Kubernetes cluster, which is exactly what we want for our internal messaging system. The selector is critical here; it tells Kubernetes how to find the pods that belong to this service.

Now that we have the Deployment and Service defined, we can install our Helm chart. From the root directory of your udemy-microsrv-cluster project, run the following command:

helm install nats .

This will install our chart with the release name nats. You can verify that everything is running correctly by using kubectl to check the pods and services:

kubectl get pods
kubectl get services

You should see a NATS pod and a NATS service listed. If you do, congratulations! You've successfully deployed NATS to your Kubernetes cluster. The key takeaway here is understanding how Deployments and Services work together to manage and expose our applications.

Adding Deployment and Service for udemy-microsrv-gateway

Next up, let's deploy the udemy-microsrv-gateway. This service will act as the entry point for our application, handling incoming requests and routing them to the appropriate microservices. Like NATS, we'll need both a Deployment and a Service for the gateway. The gateway is crucial for providing a single point of access to our microservices.

Inside the templates/ directory, create a new file named gateway-deployment.yaml and add the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: udemy-microsrv-gateway
  labels:
    app: udemy-microsrv-gateway
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udemy-microsrv-gateway
  template:
    metadata:
      labels:
        app: udemy-microsrv-gateway
    spec:
      containers:
      - name: udemy-microsrv-gateway
        image: <your-gateway-image>
        ports:
        - containerPort: 8080

Important: Replace <your-gateway-image> with the actual image name and tag for your gateway service. This image should be built and pushed to a container registry (like Docker Hub or Google Container Registry) before you deploy it to Kubernetes.

This Deployment is very similar to the NATS Deployment. We're creating a single replica of the udemy-microsrv-gateway and exposing port 8080. The labels are important for the Service to find the correct pods.

Now, let's create the Service. Create a new file named gateway-service.yaml in the templates/ directory and add the following YAML:

apiVersion: v1
kind: Service
metadata:
  name: udemy-microsrv-gateway
  labels:
    app: udemy-microsrv-gateway
spec:
  selector:
    app: udemy-microsrv-gateway
  ports:
  - port: 80
    targetPort: 8080
    name: http
  type: LoadBalancer

This Service is a bit different from the NATS Service. We're using type: LoadBalancer, which means that Kubernetes will provision a load balancer in your cloud provider (if you're running in a cloud environment) to make the gateway accessible from outside the cluster. If you're running locally (e.g., with Minikube), you might need to use type: NodePort or type: ClusterIP instead. Also, we're mapping port 80 on the load balancer to port 8080 on the gateway pods. The LoadBalancer type is essential for external access to our gateway.

To deploy the gateway, we need to update our Helm chart. The easiest way to do this is to use the helm upgrade command. From the root directory of your udemy-microsrv-cluster project, run:

helm upgrade udemy-microsrv-cluster .

This command will update our existing chart with the new Deployment and Service definitions. After the upgrade, you can check the status of the gateway pods and service using kubectl:.

kubectl get pods
kubectl get services

You should see the udemy-microsrv-gateway pod and service listed. If you used type: LoadBalancer, you should also see an external IP address assigned to the service. You can use this IP address to access your gateway from your browser or other clients. The upgrade process is a fundamental aspect of managing applications in Kubernetes.

Adding Deployments for Other Microservices

Now, let's add Deployments for the remaining microservices: udemy-microsrv-auth, udemy-microsrv-order, udemy-microsrv-payment, and udemy-microsrv-product. For these services, we'll create Deployments similar to the gateway, but we won't create Services for them directly. These services will communicate with each other internally through NATS, so they don't need to be exposed externally. Each microservice requires its own deployment for scalability and isolation.

For each microservice, create a new file in the templates/ directory following the naming convention <service-name>-deployment.yaml. Here are the YAML configurations for each service:

udemy-microsrv-auth-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: udemy-microsrv-auth
  labels:
    app: udemy-microsrv-auth
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udemy-microsrv-auth
  template:
    metadata:
      labels:
        app: udemy-microsrv-auth
    spec:
      containers:
      - name: udemy-microsrv-auth
        image: <your-auth-image>
        ports:
        - containerPort: 8080

udemy-microsrv-order-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: udemy-microsrv-order
  labels:
    app: udemy-microsrv-order
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udemy-microsrv-order
  template:
    metadata:
      labels:
        app: udemy-microsrv-order
    spec:
      containers:
      - name: udemy-microsrv-order
        image: <your-order-image>
        ports:
        - containerPort: 8080

udemy-microsrv-payment-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: udemy-microsrv-payment
  labels:
    app: udemy-microsrv-payment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udemy-microsrv-payment
  template:
    metadata:
      labels:
        app: udemy-microsrv-payment
    spec:
      containers:
      - name: udemy-microsrv-payment
        image: <your-payment-image>
        ports:
        - containerPort: 8080

udemy-microsrv-product-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: udemy-microsrv-product
  labels:
    app: udemy-microsrv-product
spec:
  replicas: 1
  selector:
    matchLabels:
      app: udemy-microsrv-product
  template:
    metadata:
      labels:
        app: udemy-microsrv-product
    spec:
      containers:
      - name: udemy-microsrv-product
        image: <your-product-image>
        ports:
        - containerPort: 8080

Remember to replace <your-auth-image>, <your-order-image>, <your-payment-image>, and <your-product-image> with the actual image names and tags for your services. The image tag is critical for version control and deployments.

We also need to add a Service for the udemy-microsrv-payment service, as it requires external access for payment processing. Create a new file named payment-service.yaml in the templates/ directory and add the following YAML:

payment-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: udemy-microsrv-payment
  labels:
    app: udemy-microsrv-payment
spec:
  selector:
    app: udemy-microsrv-payment
  ports:
  - port: 80
    targetPort: 8080
    name: http
  type: LoadBalancer

With all our Deployments and Services defined, we can update our Helm chart one last time:

helm upgrade udemy-microsrv-cluster .

After the upgrade, check the status of all the pods using kubectl get pods. You should see pods for all your microservices running. The kubectl get pods command is your go-to for checking the status of your deployments.

Conclusion

And that's it! You've successfully set up a Kubernetes cluster for your microservices. We've covered a lot of ground, from creating a Helm project to deploying multiple services with Deployments and Services. You've learned how to use Helm to manage your Kubernetes configurations and how to deploy and upgrade your applications. Remember, this is just the beginning. There's a lot more to explore in the world of Kubernetes, such as scaling, monitoring, and advanced networking. But with this foundation, you're well on your way to becoming a Kubernetes master! So, keep practicing, keep learning, and keep building awesome applications! Congrats, guys, on making it to the end of this guide! You’ve taken a significant step towards mastering Kubernetes for microservices. The journey continues, so stay curious and keep exploring!