Skip to main content
Version: Mosquitto 2.8

Introduction

Cedalo offers different Mosquitto broker configurations that you can deploy starting from single-node solutions to High Availability Cluster using docker. We also now introduce the kubernetes support for Mosquitto. Kubernetes simplifies Mosquitto broker deployment by providing automated scaling, and easy updates. Our main objective is to offer Kubernetes support for Mosquitto to add support for manual scaling, automated scaling, easier deployment and orchestration of Mosquitto resources and of course reaching a wider audience by giving access to various tech stacks. Its container orchestration streamlines management and ensures high availability, making it ideal for IoT and real-time messaging applications. Kubernetes abstracts infrastructure complexities, allowing you to focus on building robust MQTT services efficiently. Kubernetes, the go-to solution for container orchestration, offers a streamlined approach to deploying and managing applications. In this article, we'll explore some of the tools that we would be using to deploy Kubernetes setup in different versions of Mosquitto deployment.

Different Versions of Mosquitto Configuration deployment:

  • Single Node Deployment (1 Management-Center and 1 Mosquitto broker)
  • Multi-node deployment on a single host(3 Mosquitto broker and 1 Management-Center)
  • Multi Node Deployment on different Host - High Availability (3 -Mosquitto broker and 1 Management-Center)
  • Multi-node Deployment - High Availability with Autoscaling (1 Management Center, 1 NFS server, on-demand Mosquitto brokers)

Tools we would be discussing here are as follows:

  • Helm Charts (For all versions)
  • Minikube (Single node and multi-node on a single host)
  • Kubeadm and Calico(HA and HA with autoscaling)

Helm Charts​

Helm is a package manager for Kubernetes that simplifies application deployment, management, and scaling. Helm charts are predefined packages that encapsulate an application's configuration, dependencies, and runtime requirements. These charts allow you to deploy complex applications like the Mosquitto broker effortlessly. You can refer to further details about helm charts on the official documentation page. A simple helm charts deployment could like this: helm install my-mosquitto ./mosquitto-chart

Minikube:​

Minikube is a lightweight, local Kubernetes distribution and management tool that allows you to run a single-node Kubernetes cluster on your local development machine. It is designed for local development, testing, and experimentation with Kubernetes without the need for a full-fledged multi-node cluster. Here are some key features and benefits of Minikube:

  • Local Kubernetes Environment: Minikube provides a simple and convenient way to create a Kubernetes cluster on your host machine. This local cluster mimics the behavior of a full Kubernetes cluster, allowing you to develop and test applications that you plan to deploy on a production Kubernetes environment.
  • Ease of Setup: Minikube is easy to set up and use. It automates the deployment of a single-node cluster and takes care of many of the complexities of Kubernetes, making it accessible to developers who may not be Kubernetes experts.
  • Isolation: Minikube runs the Kubernetes cluster within a virtual machine or a container (depending on the driver you choose). This isolation ensures that your local cluster doesn't interfere with your machine's primary operating system or other applications.

Kubeadm​

Kubeadm is a command-line tool in the Kubernetes ecosystem designed to facilitate the process of setting up and bootstrapping a Kubernetes cluster. It's part of the Kubernetes project and serves as a simplified, but highly configurable, tool for initializing and managing a cluster. Kubeadm is particularly useful for quickly deploying Kubernetes clusters for development, testing, or small-scale production environments.Kubeadm is a valuable tool for administrators and operators who need to create and manage Kubernetes clusters quickly and consistently. It abstracts many of the complexities involved in cluster configuration, making it easier to get started with Kubernetes or manage small to medium-sized clusters efficiently.

Here are some key features and use cases for kubeadm:

  • Cluster Initialization: Kubeadm automates the process of setting up the control plane components (like the API server, controller manager, and etcd) on the master node. It helps initialize the cluster, so you don't have to configure these components manually.
  • Node Joining: Kubeadm simplifies the process of adding worker nodes to the cluster. This includes generating the necessary authentication tokens and certificates, which makes it easier to scale your cluster.
  • Cluster Configuration: Kubeadm provides sensible default configurations, but it also allows you to customise various aspects of your Kubernetes cluster by specifying configuration files.
  • Addon Support: It has built-in support for deploying common Kubernetes addons, such as the network overlay (CNI) plugin, without manual intervention.

Calico​

Calico is an open-source networking and network security solution designed for cloud-native environments, particularly for Kubernetes clusters. It provides network connectivity and security for containerized applications and is known for its simplicity, scalability, and robust features.

Key features and aspects of Calico include:

  • Network Connectivity: Calico enables containerized applications to communicate with each other, both within and across Kubernetes clusters. It sets up the necessary network routes and policies to facilitate this communication.
  • BGP-Based Routing: Calico uses Border Gateway Protocol (BGP) to route traffic within and between Kubernetes clusters. This approach is highly scalable and flexible, making it suitable for large, complex deployments.
  • Network Security: Calico offers fine-grained network security policies. It allows administrators to define rules for controlling traffic between pods, making it a valuable tool for implementing security and segmentation in Kubernetes environments.

Further common kubernetes concepts that we would using in this setup:​

  • Deployments (MMC and HA)
  • Statefulsets (Mosquitto)
  • Services (Mosquitto, MMC and HA)

Deployments:​

  • Use Case: Deployments are primarily used for managing stateless applications, where instances of the application can be easily replaced or scaled up/down without regard to their identity.
  • Scaling: Deployments provide easy scaling of applications horizontally by creating or removing replicas.
  • Rolling Updates: Deployments support rolling updates and rollbacks, making it easy to update the application to a new version or configuration while ensuring zero downtime.
  • Pod Identity: Pods managed by Deployments do not have stable network identities or storage. They are disposable, and Kubernetes may reschedule them to different nodes.

StatefulSets:​

  • Use Case: StatefulSets are designed for managing stateful applications, such as databases, where each pod has a stable and unique identity and may require ordered, sequential scaling or rolling updates.
  • Pod Identity: Pods managed by StatefulSets are assigned a stable hostname and storage identity. They are often used for distributed systems where pod identity is critical for operations like failover, sharding, and replication.
  • Scaling: StatefulSets support ordered scaling. You can specify how many replicas you want, and they are created in order, ensuring predictable naming and network identities.
  • Rolling Updates: StatefulSets also support rolling updates, but they are designed to handle the complexity of updating stateful applications while maintaining their unique identities.

In summary, Deployments are suitable for stateless applications, offering easy scaling and rolling updates. StatefulSets, on the other hand, are designed for stateful applications that require stable identities and predictable, ordered scaling. The choice between the two depends on the specific requirements of your application. StatefulSets are essential for scenarios like running databases in Kubernetes, while Deployments are more suitable for typical web services and microservices.

Services​

In Kubernetes, a "Service" is an abstraction that defines a logical set of pods and a policy by which to access them. It acts as a stable endpoint for communication, allowing other services or external users to interact with applications running within a Kubernetes cluster without needing to be aware of the specific details of how those applications are deployed or scaled.

Here are the key aspects of Kubernetes Services:

  • Load Balancing: Services provide load balancing across a set of pods. They ensure that network traffic is distributed fairly and efficiently among the pods that belong to the service. This load balancing is crucial for high availability and scalability.

  • Stable Endpoint: Each service is assigned a stable IP address or DNS name, which doesn't change even if pods come and go due to scaling or failures. This stable endpoint simplifies the process of connecting to the application.

  • Label-Based Selection: Services select pods based on labels and label selectors, making it easy to specify which pods should be part of the service. This label-based selection allows dynamic membership management.

    Types of Services:​

  • ClusterIP: The default service type, accessible only within the cluster.

  • NodePort: Exposes the service on each node's IP at a static port on the node. This makes the service accessible externally at the specified port.

  • LoadBalancer: Provides an external IP address that routes traffic to the service. This is primarily used when running Kubernetes in a cloud environment that supports load balancers.

  • ExternalName: Maps the service to a DNS name. It doesn't create a cluster IP or load balancer. It's used to make services accessible as external names, often pointing to resources outside the cluster.

  • Service Discovery: Services enable easy service discovery within the Kubernetes cluster. Other pods or services can discover and connect to the service using its DNS name or IP address.

  • Headless Service: You can create a "headless" service, which doesn't provide a cluster IP but instead allows direct DNS-based communication with individual pods, useful for certain specialized use cases like StatefulSets.

Kubernetes Services are a fundamental component for building scalable and resilient applications within a cluster. They abstract the network and routing complexities, allowing developers and operators to focus on the application logic while ensuring reliable communication and load distribution. We would be using different services for different types of applications:

  • Headless Service (Mosquitto)
  • NodePort: (MMC and HA)